Skip to content
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

Closed
rh-hemartin opened this issue Mar 15, 2024 · 6 comments · Fixed by #7799
Closed

APIServerSource filter event type sent to sink #7791

rh-hemartin opened this issue Mar 15, 2024 · 6 comments · Fixed by #7799
Assignees
Labels
kind/feature-request triage/accepted Issues which should be fixed (post-triage)

Comments

@rh-hemartin
Copy link
Contributor

rh-hemartin commented Mar 15, 2024

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.

@pierDipi
Copy link
Member

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

@knative-prow knative-prow bot added the triage/accepted Issues which should be fixed (post-triage) label Mar 15, 2024
@rh-hemartin
Copy link
Contributor Author

rh-hemartin commented Mar 15, 2024

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?

@pierDipi
Copy link
Member

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'

@Cali0707
Copy link
Member

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

@rh-hemartin
Copy link
Contributor Author

rh-hemartin commented Mar 18, 2024

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.

@pierDipi
Copy link
Member

/assign @rh-hemartin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature-request triage/accepted Issues which should be fixed (post-triage)
Projects
Development

Successfully merging a pull request may close this issue.

3 participants