We need a ruby gRPC shim for existing Ruby Sensu extensions. The shim should start a long-running process with a gRPC server that instantiates the provided extension, sends incoming requests to the extension, and generates a response based on the output of the extension's safe_run method.
Extensions currently believe they are running in the EM reactor.
We need to accommodate this use case for stateful extensions that do crazy things like buffer metrics to be flushed over the network to graphite servers.
The EM+gRPC server shim should take a configurable listen address supplied via the command line or environment variable.
See #340 for the CLI specification.
@sinthetix @echlebek Let's get on a call this week to clarify things, I think we all have a different idea of what this is.
i have no idea so yeah, i guess that's different 馃槈

Is this still planned for GA? It's my understanding that the Extensions API is effectively complete but I see this as the last remaining issue in the Extensions milestone epic.
I'm pretty sure that someone has this working somewhere already.
Check with @jspaleta or maybe @cyphus -- they're the last two people I recall looking at this.
This feature is incomplete after over a year. We need to reassess if this is something we are ever actually going to develop. It seems that people find ruby assets preferable to extensions in their current form. Thinking about the UX of extensions (not so good), I think I can see why.
Let's decide if we are going to use extensions. If we are going to use them, let's make them easier to use for 90-95% of the things we need them for. If we can't commit to doing that work, I think we should consider scrapping the extensions feature.
Closing, this is not something we are going to do.
Hey I realize this is already closed but in case it's ever opened again I thought I'd reference the proof-of-concept Ruby gRPC shim for 1.x filters https://github.com/sensu/sensu-1.x-filter-wrapper
It was created with the purpose of having an answer in case any of Sensu's customers asked for the ability to use 1.x filters in a 2.x environment at some point during the 2018 Sensu Summit. Such a thing never ended up being asked for, so I think closing this issue is the right idea 馃憤
Thanks, @cyphus! Noted for posterity! 馃憤
I hope all is well!
Most helpful comment
Hey I realize this is already closed but in case it's ever opened again I thought I'd reference the proof-of-concept Ruby gRPC shim for 1.x filters https://github.com/sensu/sensu-1.x-filter-wrapper
It was created with the purpose of having an answer in case any of Sensu's customers asked for the ability to use 1.x filters in a 2.x environment at some point during the 2018 Sensu Summit. Such a thing never ended up being asked for, so I think closing this issue is the right idea 馃憤