New trigger filters

Flag name: new-trigger-filters

Stage: Beta, enabled by default

Tracking issue: #5204

Overview

This experimental feature enables a new filters field in Triggers that conforms to the filters API field defined in the CloudEvents Subscriptions API. It allows users to specify a set of powerful filter expressions, where each expression evaluates to either true or false for each event.

The following example shows a Trigger using the new filters field:

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. name: my-service-trigger
  5. spec:
  6. broker: default
  7. filters:
  8. - cesql: "source LIKE '%commerce%' AND type IN ('order.created', 'order.updated', 'order.canceled')"
  9. subscriber:
  10. ref:
  11. apiVersion: serving.knative.dev/v1
  12. kind: Service
  13. name: my-service

About the filters field

  • An array of filter expressions that evaluates to true or false. If any filter expression in the array evaluates to false, the event will not be sent to the subscriber.
  • Each filter expression follows a dialect that defines the type of filter and the set of additional properties that are allowed within the filter expression.

Supported filter dialects

The filters field supports the following dialects:

exact

CloudEvent attribute String value must exactly match the specified String value. Matching is case-sensitive.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - exact:
  9. type: com.github.push

prefix

CloudEvent attribute String value must start with the specified String value. Matching is case-sensitive.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - prefix:
  9. type: com.github.

suffix

CloudEvent attribute String value must end with the specified String value. Matching is case-sensitive.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - suffix:
  9. type: .created

all

All nested filter expressions must evaluate to true.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - all:
  9. - exact:
  10. type: com.github.push
  11. - exact:
  12. subject: https://github.com/cloudevents/spec

any

At least one nested filter expression must evaluate to true.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - any:
  9. - exact:
  10. type: com.github.push
  11. - exact:
  12. subject: https://github.com/cloudevents/spec

not

The nested expression evaluated must evaluate to false.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - not:
  9. exact:
  10. type: com.github.push

cesql

The provided CloudEvents SQL Expression must evaluate to true.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. ...
  5. spec:
  6. ...
  7. filters:
  8. - cesql: "source LIKE '%commerce%' AND type IN ('order.created', 'order.updated', 'order.canceled')"

Conflict with the current filter field

The current filter field will continue to be supported. However, if you enable this feature and an object includes both filter and filters, the new filters field overrides the filter field. This allows you to try the new filters field without compromising existing filters, and you can introduce it to existing Trigger objects gradually.

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4. name: my-service-trigger
  5. spec:
  6. broker: default
  7. # Current filter field. Will be ignored.
  8. filter:
  9. attributes:
  10. type: dev.knative.foo.bar
  11. myextension: my-extension-value
  12. # Enhanced filters field. This will override the old filter field.
  13. filters:
  14. - cesql: "type = 'dev.knative.foo.bar' AND myextension = 'my-extension-value'"
  15. subscriber:
  16. ref:
  17. apiVersion: serving.knative.dev/v1
  18. kind: Service
  19. name: my-service

FAQ

Why add yet another field? Why not make the current filter field more robust?

The reason is twofold. First, at the time of developing Trigger APIs, there was no Subscriptions API in CloudEvents Project, so it makes sense to experiment with an API that is closer to the Subscriptions API. Second, we still want to support users workload with the old filter field, and give them the possibility to transition to the new filters field.

Why filters and not another name that wouldn’t conflict with the filter field?

We considered other names, such as cefilters, subscriptionsAPIFilters, or enhancedFilters, but we decided that this would be a step further from aligning with the Subscriptions API. Instead, we decided it is a good opportunity to conform with the Subscriptions API, at least at the field name level, and to leverage the safety of this being an experimental feature.