As described in the MVP doc, we want to not only create a trigger, but also create an associated source CR, whose results only go to that trigger.
The feature described in this issue add the possibility to specify a source when creating a trigger. It is based on #479 and has the trigger creation without source as a prerequisite.
Copy of the spec related to implicit source creation:
....
In addition to the trigger, an additional Source can be created automatically like with kn source create. The difference to kn source create is, that the source is connected exclusively to this trigger (and you automatically use the same broker). The source type is provided with a --source option.
Except that the Source's sink can't be specified, all other, source specific commands are available. These can be given after a --(two dashes) separator on the command line which indicates the end of the trigger specific options. The following example will create the same trigger as above, but also instantiate a generic source for the storage CRD:
# Create a trigger + a storage generic source
$ kn trigger create ochoa \
--sink event-display \
--filter "type=dev.knative.foo" \
--source generic \
-- \
--source-name storage \
--event-types finalize \
--parameters "bucket=my-bucket" \
--secret "gcsSecret=google-cloud-key:key.json"
For the options possible after the delimiter (--) see kn source create. Whether the delimiter is required depends on the likelihood that a typed source might also use the --filter or --broker options.
Only sources which support the ceOverride mechanism as described in Knative Eventing Source Spec can be used together with a Trigger in this way as this override is used to connect the Source exclusively to this trigger by creating a unique value, which is added to every event and a Trigger filter which filters exactly on this unique value. So it's also a task of this command to verify whether the given source supports this feature. For generic Sources, the openAPIV3 schema as given by the CRD needs to be examined, for typed Sources, all built-in sources should support this and plugins will add this information (supported: yes/no) in its manifest command.
When making a Source too, the CLI will create the Trigger and the Source simultaneous and waits by default until the Source is ready (the same behaviour like for kn service create, which supports also an --async flag). This should be idempotent, such that if the Trigger creates succeeds, then the Source create fails, the user should be able to rerun the same command to try again. Deleting the Trigger will delete the Source (via Kubernetes garbage collection).
The example above would create the following CO:
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: ochoa
namespace: default
annotations:
knative.dev/dependency: '{"kind":"Storage","name":"ochoa","apiVersion":"events.cloud.run/v1alpha1"}'
spec:
broker: default
filter:
attributes:
# This attribute is injected by the CLI into both the
# Trigger and the Source to link them.
knsourcetrigger: storages.events.cloud.run/namespaces/default/names/ochoa
type: dev.knative.foo
subscriber:
ref:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
name: event-display
---
apiVersion: events.cloud.run/v1alpha1
kind: Storage
metadata:
name: ochoa
namespace: default
ownerReferences:
- apiVersion: eventing.knative.dev/v1alpha1
controller: true
kind: Trigger
name: ochoa
uid: ce9350a1-c8fb-11e9-9d25-42010a8000a0
spec:
bucket: my-bucket
ceOverrides:
extensions:
knsourcetrigger: storages.events.cloud.run/namespaces/default/names/ochoa
eventTypes:
- finalize
gcsSecret:
name: google-cloud-key
key: key.json
sink:
apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
name: default
As described in the MVP doc, we want to not only create a trigger, but also create an associated source CR, whose results only go to that trigger.
The feature described in this issue add the possibility to specify a source when creating a trigger. It is based on #479 and has the trigger creation without source as a prerequisite.
Copy of the spec related to implicit source creation:
....
In addition to the trigger, an additional Source can be created automatically like with kn source create. The difference to kn source create is, that the source is connected exclusively to this trigger (and you automatically use the same broker). The source type is provided with a --source option.
Except that the Source's sink can't be specified, all other, source specific commands are available. These can be given after a --(two dashes) separator on the command line which indicates the end of the trigger specific options. The following example will create the same trigger as above, but also instantiate a generic source for the storage CRD:
For the options possible after the delimiter (--) see kn source create. Whether the delimiter is required depends on the likelihood that a typed source might also use the --filter or --broker options.
Only sources which support the ceOverride mechanism as described in Knative Eventing Source Spec can be used together with a Trigger in this way as this override is used to connect the Source exclusively to this trigger by creating a unique value, which is added to every event and a Trigger filter which filters exactly on this unique value. So it's also a task of this command to verify whether the given source supports this feature. For generic Sources, the openAPIV3 schema as given by the CRD needs to be examined, for typed Sources, all built-in sources should support this and plugins will add this information (supported: yes/no) in its manifest command.
When making a Source too, the CLI will create the Trigger and the Source simultaneous and waits by default until the Source is ready (the same behaviour like for kn service create, which supports also an --async flag). This should be idempotent, such that if the Trigger creates succeeds, then the Source create fails, the user should be able to rerun the same command to try again. Deleting the Trigger will delete the Source (via Kubernetes garbage collection).
The example above would create the following CO: