Support for Message Bus Consumers

[BradleyMcCallionCOT]

Please describe your use case / problem.
I really want to integrate Telepresence into our SDLC. However, a large part of our stack involves message bus consumer which are triggered by consuming messages off a queue rather than HTTP requests. The personal intercepts feature works via HTTP headers so this is obviously not compatible with message bus handlers.

Describe the solution you'd like
A feature in Telepresence which allows for a similar personal intercept for Message Bus Handlers -- a local version of a message bus handler consumes messages with a metadata field relating to the personal intercept while the real version continue running and handles all other messages.

Describe alternatives you've considered
A manual solution where the publisher publishes to a new temporary topic suffixed with the personal intercept ID when it is triggered by a request with a personal intercept header. E.g. normal topic is Foo. But if the header triggering the publishing comes in with the header Personal-Intercept=12345 then it publishes to Foo-12345 and the local version of the consumer is set to consume from this.

[thallgren]

This is a very hard problem to solve, for several reasons:

1. A container that somehow consumes events does that by first opening a connection to a provider, and then it consumes messages from that provider. When the container starts, this intent to open a connection is not declared anywhere, so there's no way to intercept it.

2. While the message provider/consumer protocol may contain meta-data similar to http headers, there's no guarantee that the http protocol is used. So in order to intercept the traffic, Telepresence would be required to understand the protocol used by the message queue solution.

3. Personal intercepts based on http-header filtering, is an enterprise feature. Telepresence OSS intercepts tcp or udp traffic only, which means that it isn't concerned with parsing any content, nor does it need to terminate or originate SSL or worry about header-propagation being performed between services. I'm reluctant to introduce that kind of complexity in the OSS product.

Telepresence OSS now provides a telepresence replace command. One use case where it's very handy is for message consumers. It doesn't provide any meta-data filtering of course, but it guarantees that the original consumer no longer runs. I'm afraid that's the best we can provide at this point.

[BradleyMcCallionCOT]

Thanks for the prompt response. I suspected this response but thought I would just ask in case the team had any bright ideas they were working on.