-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APIServerSource filter event type sent to sink #7791
Comments
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/ /triage accepted |
So the idea would be to add a
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' |
@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 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 |
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 forcreate
,update
anddelete
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 theupdate
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.
The text was updated successfully, but these errors were encountered: