eventing icon indicating copy to clipboard operation
eventing copied to clipboard

APIServerSource filter event type sent to sink

Open rh-hemartin opened this issue 1 year ago • 6 comments

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.

rh-hemartin avatar Mar 15 '24 08:03 rh-hemartin

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

pierDipi avatar Mar 15 '24 09:03 pierDipi

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?

rh-hemartin avatar Mar 15 '24 12:03 rh-hemartin

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 avatar Mar 15 '24 14:03 pierDipi

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

Cali0707 avatar Mar 15 '24 14:03 Cali0707

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.

rh-hemartin avatar Mar 18 '24 07:03 rh-hemartin

/assign @rh-hemartin

pierDipi avatar Mar 25 '24 17:03 pierDipi