kn trigger create - create a source implicitely (based on #479)

[sixolet]

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

[rhuss]

Updated description with the content of the spec (which remains the authorative document)

[github-actions]

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.

[navidshaikh]

/reopen
/remove-lifecycle stale

[knative-prow-robot]

@navidshaikh: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle stale

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.

[github-actions]

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.

[rhuss]

Not sure if this story is relevant anymore.

Anybody supporting this feature, please remove the 'stale' label. Otherwise I would let fade out this feature proposal.

[github-actions]

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.