APIServerSource filter event type sent to sink
Problem Currently APIServerSource sends create, update and delete event types to the sink specified. Our use case can benefit of receiving just delete events instead. This will reduce the load our receiver experiences. Instead of discarding the message on the receiver we will discard it on the producer (the APIServerSource).
The APIServerSource resource could support an additional optional property called spec.eventTypes that is a list that allows for create, update and delete as values. By default the three of them would be specified, so the current behaviour is retained.
This introduces a if/else for each message so performance is reduced for the default case (current behavior), however there are performance gains when some events are excluded. The most important performance gain would be if the user removes the update event type. I'm trying to come up with a solution that does not reduce performance for the default case.
Persona: Which persona is this feature for? Event Consumer and Event Producer
Exit Criteria The event types sent to the sink are of the type selected.
This makes a lot of sense!
I think re-using the new filters API for this specific source makes sense: https://knative.dev/docs/eventing/experimental-features/new-trigger-filters/ It is a more powerful filtering mechanism than just types and will also provide UX consistency across APIs.
/triage accepted
So the idea would be to add a filters instead that enables the user to do things like (don't mind the indentation, couldn't get it right):
kind: APISourceServer
...
spec:
filters:
- exact:
type: dev.knative.apiserver.resource.delete
- exact:
type: dev.knative.apiserver.resource.create
Or other filtering based on the filters API. I understood that correctly?
yes, kinda, for your use case, it would provide a few alternatives:
spec:
filters:
- any:
- exact:
type: dev.knative.apiserver.resource.delete
- exact:
type: dev.knative.apiserver.resource.create
alternative with a SQL-like expression:
spec:
filters:
- cesql: "type LIKE '%create' OR type LIKE '%delete'
I think re-using the new filters API for this specific source makes sense: https://knative.dev/docs/eventing/experimental-features/new-trigger-filters/ It is a more powerful filtering mechanism than just types and will also provide UX consistency across APIs.
@pierDipi would this also be behind the same feature flag as those filters? I agree it makes sense to use them here, just trying to think of the details
I think it would make more sense to put it behind another flag, something like new-apiserversource-filters?
By the way, I'm willing to contribute this change, so I'm assigning myself.
Edit: I could not assign myself, makes sense as I'm not part of the repository. I opened a PR.
/assign @rh-hemartin