Conditional Routing

[lionelvillard]

Problem
There is currently no easy way to route events based on some arbitrary conditional logic.

This is problem for both, eventing and messaging. For eventing, a route corresponds to a trigger (but filtering is very limited #930). For messaging there is no support at all (other than implementing the logic in functions)

Persona:
Event Consumer

Additional context (optional)

• messaging vs eventing
• A case for routing
• MLGraph proposal

Related issues:

• Advanced Filtering on Triggers #930
• Advertise current filters to upstream event publishers #934
• Add content-based event filtering #1310

[duglin]

@lionelvillard there's also the abstract concept of routing to versions of a service based on something other than the %-based routing we have today in the KnService traffic block. Do you see this issue as fundamentally a different problem or a variant of it? I suspect it's different since I think in this one you're talking about "choosing which service to route to" while the other idea is "choosing which version of one service to route to", but I do wonder if there could be some overlap (or at least synergy) if the event routing needs to route to different versions of the service.

[lionelvillard]

@duglin There is definitively some overlaps between service mesh routing vs application-level routing, eg. routing based on HTTP headers. Maybe some of the conditions expressed at the application level can be "pushed down" to the service mesh level, for better performance.

[lionelvillard]

Here a strawman proposal: https://docs.google.com/document/d/1Yzvr6WFq1F9d6y-h-bMTK69FlU4jSgD5u9G9XAqZvx4/edit

[ukclivecox]

@lionelvillard Your routing proposal covers what we need for MLGraph routing use case. In our case we would create GenericRouters to cover the "multi-armed bandit" routers we need.

We also need state management but that sounds like a separate discussion in the knative world.

[evankanderson]

For the "Join" operation, can you use a key-value store like Redis or Memcache for state management, rather than keeping the state in-process?

Other than that, Broker/Trigger is intended to provide the multi-armed bandit solution (assuming that you actually mean "independent selection of events on each subscriber" and not the Machine Learning technique); the current implementation is naive, but I'd love to see a proposal to measure and improve the overhead.

For messaging, a CRD that implements the Message Router pattern or the Content-Based Router pattern seems generally useful, and should only need a single CRD (since there is a select-one rather than fanout, so users probably want to resolve conflicts intentionally).

[ukclivecox]

@evankanderson For our MLGraph use case mentioned we do mean the machine learning multi-armed bandit solvers - so stateful algorithms that decide a route. I see a simple solution where they add headers so the usual triggers can be activated. Not sure if this could be covered by @lionelvillard proposals. State management could be handled as you said by a Redis/Memcache store and left up to the implementations to use it otherwise a more complex based solution as suggested by Akka could be investigated.

For Join our MLGraph use case is for ensembling where you join together a set of responses into a single response. For that we would need some management to know when we have received all the messages flowing through the graph for a single input request for the "join" component to process.

[n3wscott]

also related to #3359

[skonto]

@n3wscott, @lionelvillard @evankanderson @slinkydeveloper @matzew I have created a related proposal, let me know WDYTH.

[n3wscott]

@skonto interesting! We have been looking at using the CloudEvents subscription api to propagate the filters from the broker to the upstream sources, allowing filtering to happen as close to the source as possible, do you think that would let you do what you are thinking about?

[skonto]

@n3wscott yes the idea is to do the filtering or similar logic at the source (client runtime or via a broker-like side-car in this context), as streaming engines or other frameworks do it to avoid the overhead eg. pushing down to a db a predicate.