[Experimental] Enhanced Trigger filters via adopting CloudEvent Subscriptions API

[slinkydeveloper]

Description

Trigger Filter API should conform to the CNCF CouldEvents Subscriptions API in order to support more complex predicates, the newly born CloudEvents Expression Language and any additional custom language/predicate vendors wants to include in their offerings.

Feature Track

https://hackmd.io/@devguyio/H1Mg3my2d

Why

1. Provide a more flexible Trigger API that provides a better UX for Knative users and better suits users production needs.
2. Used as a first step towards evaluating the possibility of standardizing our API shape to the CloudEvents Subscriptions API.

Exit Criteria

Trigger filter supports the filters API field defined in the Subscriptions API.

Deciding on the Future of The Experimental Feature

The User Experience WG would significantly help by conducting user feedback surveys and gather feedback from Knative users, PMs and vendors to decide on the future of this feature.

Experimental feature stages plan

Below the proposed plan for the feature stages (this list implicitly includes the requirements defined in the process)

• Alpha:
  • [x] Implement in the API code the required changes to conform to the Subscription API https://github.com/knative/eventing/pull/5205
  • [x] Implement in mtbroker the new filter predicates + vendorable e2e tests, to let downstream implementations test it
  • [x] User documentation
• Beta graduation as soon as 1 release after the inception
• Beta:
  • [x] Implementation improvements, possibly leveraging and expanding eventfilter module benchmarks
  • [ ] User documentation stabilization and improvements
  • [x] More e2e tests
  • [ ] Add conformance tests
• Stable graduation as as soon as the CNCF Subscription spec is released as a stable version
• Stable:
  • [ ] Add the requirement to support CNCF subscription filters to the knative/specs repo: https://github.com/cloudevents/spec/pull/803

Affected WG

• Eventing WG

Prior discussions

• https://github.com/knative/eventing/issues/3359
• https://github.com/knative/eventing/pull/3771
• https://github.com/knative/eventing/issues/3819
• https://github.com/knative/eventing/issues/930
• https://github.com/knative/eventing/pull/4529
• https://docs.google.com/document/d/1H8WNW2gntwXSv9k2DrA6aS6STRQv_HRq2pdayo334F8/edit?usp=sharing

[slinkydeveloper]

/assign

[slinkydeveloper]

cc @duglin

[lberk]

@slinkydeveloper just curious -- did you see this as being a subsequent effort/included to the feature gating/experimental feature process? Your awesome proposal lists this as an example but I didn't see it listed in the steps for the issue -- just wanted to check out loud

[slinkydeveloper]

@lberk I'm waiting for the experimental features proposal to be accepted to refactor this issue and move forward with the process

[slinkydeveloper]

@lberk refactored as experimental feature :)

[devguyio]

/assign

[devguyio]

Some updates

• Updated the description of the issue.
• Created a new Feature Track (link above).

@omerbensaadon @csantanapr would be great to give your feedback specially with the suggested involvement of the UX WG.

@vaikas @lionelvillard @n3wscott @matzew @slinkydeveloper PTAL as tech WG leads.

[omerbensaadon]

@slinkydeveloper @devguyio can someone bring this to the DUX WG call tomorrow?

[duglin]

obviously I think this is great! :-) Nice write-up!

[devguyio]

@evankanderson I've responded to your comments on the Feature Track doc

[devguyio]

@matzew responded to your comment.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[pierDipi]

/remove-lifecycle stale /triage accepted /reopen

[knative-prow-robot]

@pierDipi: Reopened this issue.

In response to this:

/remove-lifecycle stale /triage accepted /reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[matzew]

/assign @matzew

[Cali0707]

/assign

[Leo6Leo]

• Prefix filter: Only allows data that starts with a specific string
• Suffix filter: Only allows data that ends with a specific string
• Exact filter: Only allows data that exactly matches a specific string
• Not filter: Excludes data that matches a certain criterion
• Any filter: Allows data that matches any of a list of criteria
• All filter: Allows data that matches all of a list of criteria

[Cali0707]

@pierDipi how many releases should we wait here before starting to move it to GA?

[hamishforbes]

Hi, I understand this feature is beta and enabled by default, but how can I go about trying out the new filters field? It's not included in the released CRDs. Is there a way to generate the CRDs including beta fields or something? Or do I just have to manually hack it into the CRDs installed on my clusters to try it out?

[Cali0707]

Hi @hamishforbes thanks for catching this! Because the trigger CRD hasthe x-kubernetes-preserve-unknown-fields: true property, you can just add the filters field to your triggers and it should work. I hadn't realized that we had not yet added filters to the CRD, I've opened an issue to fix that. If you run into any issues using the new trigger filters please let us know!