Be able to generate events with different eventNames from a single data source
Is your feature request related to a problem? Please describe. Today, one EventSource object can be configured with multiple events configuration, this can reduce the K8s resources usage such as the number of created pods. For example, you can configure a Kafka EventSource object, with 2 events, both pointing to the same kafka topic, but using 2 different event source filters. However, this sort of EventSource configuration can not reduce the connection to the kafka brokers, if that particular kafka topic is used for many event sources, that will use lots of client subscriptions.
Describe the solution you'd like
- An event source can be used to subscribe to a single data source, using filters to publish events with different eventNames.
- This should support all the existing event sources.
Describe alternatives you've considered This could be achieved by extending existing EventSource spec, or adding a new CRD.
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
From the documentation, I would have implied that this feature is already in place. But i tried it with the webhook, and I am getting a weird behaviour:
From the documentation, I would have implied that this feature is already in place. But i tried it with the webhook, and I am getting a weird behaviour:
This feature request is different from the documentation.
From the documentation, I would have implied that this feature is already in place. But i tried it with the webhook, and I am getting a weird behaviour:
What was the weird behavior?
So I had 2 events (e1 and e2) from the same event source (a webhook), and a sensor listening to these events and starting a workflow (w1 or w2) accordingly. When I wrote this message, I was seeing that when event e1 fired, nothing would start. However, when e2 fired, both w1 and w2 would start. Then I put conditions in the sensor trigger, and it was working as expected. I still think that is a bug though, because if no conditions are in place I would expect both events to trigger both workflows.
If you define both dependencies (2 events) in one sensor, by default the triggers use && operator unless you explicitly define trigger conditions. See https://github.com/argoproj/argo-events/blob/master/docs/sensors/trigger-conditions.md#triggers-without-conditions