kn source <type> - manage untyped sources

[sixolet]

Add CRUD management for untyped sources as described in the spec

---

• kn source <type> create
• kn source <type> update
• kn source <type> describe
• kn source <type> delete

---

Untyped Sources

kn source storage create desjani \
    --event-type finalize \
    --parameter "bucket=my-bucket" \
    --ce-extension-override "customceattribute=my-value" \
    --secret "gcsSecret=google-cloud-key:key.json" \
    --sink broker:default

The type argument right after source ("storage" in this example) is a Guessable CRD name and the following flags are available:

• --event-type - The list of event types to include in spec.eventTypes. This option can be given multiple times to specify multiple event types to put into this array. This field "eventTypes" is supported by GCS Storage and GitHubSource.

Note: It's not part yet of the forthcoming Source specification so describes a property which is only available for selected sources (like GitHub Source). In that sense, it would be a better fit for --parameter, but has the difficulty that is describes an array like structure which can be matched nicely.

• --ce-extension-override - Key-value pairs that are CloudEvent attributes that will be forced into all CloudEvents generated by this source. See Adding Source Spec. eventing#1856 for the specification of this CE extension field within a Knative Eventing source. This option has the format --ce-extension-override key=value and can be given multiple times on the command line in order to specify multiple overrides for extension attributes.

• --parameter - The generic key-value parameters for creating this source CO. They will map as spec.<key> = <value>. Values can only be strings and this option can be given multiple times. At the moment only top-level spec fields are supported. From the CRDs schema the type of the field specified by is inferred:

  • If specifies a scalar type, then is converted from a string to this datatype which is possible for certain types only. An error is shown if multiple --parameter options are given for this or when the conversions fails.
  • If points to an array type, --parameter can be given multiple times for this key and an array is build up from the given s. These s are converted the same way as for a scalar type.

  However, see the remark above how a mapping from flat CLI parameters to deeply nested CO fields can be achieved in the future.

• --secret - A way to inject a secret reference into the source CO's spec. The flag is written as 'specField=secretName:key' such that the CO's spec.specField is set to a SecretReference with the name 'secretName' and key set to 'key'. This mechanism can be used to inject a secret reference, as used by GcsSource, GitHubSource (for the fields spec.accessToken and spec.secretToken), GcpPubSubSource, etc.

When an option mapping is specified like in

{
  "name" : "access-token",
  "path" : ".spec.accessToken.secretRef",
  "help" : "GitHub access token. The value of this option is the name of a secret and key within secret to GitHub access, dot separated (e.g. --access-token=mygithubsecret.mykey)",
  "type" : "secret-reference"
}

and added as annotation to the source CRD, then a custom type "secret-reference" marks this option as a selectable secret. This specification above would lead to a CLI usage like in --access-token mysecret:mytokenkey and kn would know how to create a selectable secretreference from this value (because of this CLI type).
Additionally more fixed options can be added when fields become part of the Source specification. E.g if a serviceAccount field gets introduced to specify a service account for the work load, then this can be directly translated to a --service-account argument for a generic source. In the meantime, such top-level fields, which are commonly used but not standardized can be set via --parameter (e.g --parameter serviceAccount=mysa for a top-level field serviceAccount)