Problem
Currently in Knative you can filter Trigger events based on two fields of a Cloud Event:
Source
Type
As discussed in the #1381 we have decided to introduce a convention for defining an instance of an importer (or function) by adding an attribute to CloudEvent called ‘sourceid’ (working name). In order to support filtering based on that, we’ll need to modify the Trigger to be able to filter on that field.
Additionally, there are classes of applications that are built using a decorator pattern, where a function takes in an event and then decorates it (pre-processes it, adds some semantic meaning to it, etc.) and then sends it back to the broker. With the current model, the developer has to create a new event type rather than use the original event type in order to be able to create triggers to it.
Proposal
Currently the TriggerFilter looks like this:
type TriggerFilter struct { SourceAndType *TriggerFilterSourceAndTypejson:”sourceAndType,omitEmpty”}
We propose that we mark SourceAndType as deprecated, add a map that allows the user to specify any CloudEvent Context attribute field to match exactly the specified string. Excludes data attribute.
type TriggerFilter struct { // Deprecated SourceAndType *TriggerFilterSourceAndTypejson:”sourceAndType,omitEmpty”Attributes map[string]stringjson:"attributes,omitEmpty"}
The attributes map matches the event if all fields specified in the attributes map are present on the event, and all have equal values to their value on the event.
Persona:
Developer
Exit Criteria
Once a developer can create Triggers that filter based on any Cloud Event attribute (except data).
Time Estimate (optional):
1-2
Additional context (optional)
Add any other context about the feature request here.
Problem
Currently in Knative you can filter Trigger events based on two fields of a Cloud Event:
Source
Type
As discussed in the #1381 we have decided to introduce a convention for defining an instance of an importer (or function) by adding an attribute to CloudEvent called ‘sourceid’ (working name). In order to support filtering based on that, we’ll need to modify the Trigger to be able to filter on that field.
Additionally, there are classes of applications that are built using a decorator pattern, where a function takes in an event and then decorates it (pre-processes it, adds some semantic meaning to it, etc.) and then sends it back to the broker. With the current model, the developer has to create a new event type rather than use the original event type in order to be able to create triggers to it.
Proposal
Currently the TriggerFilter looks like this:
type TriggerFilter struct { SourceAndType *TriggerFilterSourceAndTypejson:”sourceAndType,omitEmpty”}We propose that we mark SourceAndType as deprecated, add a map that allows the user to specify any CloudEvent Context attribute field to match exactly the specified string. Excludes data attribute.
type TriggerFilter struct { // Deprecated SourceAndType *TriggerFilterSourceAndTypejson:”sourceAndType,omitEmpty”Attributes map[string]stringjson:"attributes,omitEmpty"}The attributes map matches the event if all fields specified in the attributes map are present on the event, and all have equal values to their value on the event.
Persona:
Developer
Exit Criteria
Once a developer can create Triggers that filter based on any Cloud Event attribute (except data).
Time Estimate (optional):
1-2
Additional context (optional)
Add any other context about the feature request here.