kn trigger create

[sixolet]

Create a trigger with kn as described in the spec:

In this issue the creation of a trigger without the implicit souce creation is tracked. It is only about the creation of a plain trigger, source creation along with the trigger is tracked in #498

---

This command creates a Trigger and can optionally create a Source as well. If a source is created together with the trigger, then only events generated by that specific source instance will be seen by the Trigger.

$ kn trigger create geary \
    --sink sockeye \
    --filter type=dev.knative.foo \
    --filter customceattribute=myvalue

In this example only a trigger with name "geary" is created. kn trigger create evaluates the following arguments:

• --broker - The Broker this Trigger associates with. Defaults to 'default' if not specified.
• --filter - A key-value pair for exact CloudEvent attribute matching against incoming events. Only those that match will be seen by the subscriber. This option can be given multiple times and the filter are combined logically with AND (i.e. all filters must pass for the event to get delivered).
• --sink - The name of the sink to which events should be delivered. The value for this argument follows naming scheme described in Sink Specification If an event passes the filter, then it is sent to this specified sink.
  The resulting Trigger CO looks then like:

kind: Trigger
apiVersion: eventing.knative.dev/v1alpha1
metadata:
  name: geary
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      customceattribute: myvalue
      type: dev.knative.foo
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: sockeye

[rhuss]

As this story's feature is a subset of #498 I think we can either close this one (and implement as part of #498), or focus in #498 only on creating the source, with this feature as a mandatory requisite. I think the later is clearer so I'm going to narrow the scope of #498 and mention this issue as a prerequisite.

Also, we don't have yet discussed trigger updates in the spec. Either we forgot that totally ;-) or we might also take the POV that triggers are immutable and one would need a delete-create cycle for an update (which would make things simpler). Any opinions on this ?

[rhuss]

I updated the comment the description with the content of the spec (which remains the authoritative document)

[daisy-ycguo]

Assign myself to work on this feature.
/assign