kamelets: source/sink binding

[lburgazzoli]

To have a generic mechanics to use kamelet to materialize sources and sinks, we should introduce a new resource named KameletBinding like:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: twitter-directmessage-source
spec:
  configuration:
    - type: "property"
      value: "key=value"
    - property:
        name: user
        value: my-user
    - property:
        name: password
        valueFrom:
          secretKeyRef:
            name: the-password
            key: password
  source:
    ref:
      apiVersion: camel.apache.org/v1alpha1
      kind: Kamelet
      name: twitter-directmessage
  sink:
    ref:
      apiVersion: messaging.knative.dev/v1alpha1
      kind: InMemoryChannel
      name: twitter

The operator should translate the binding into a real integration as example, for knative sources and sinks it could generate a source like:

- from:
    uri: "kamelet:witter-directmessage"
    steps:
      - to: "knative:channel/twitter"

[nicolaferraro]

Can we have something like this instead:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: twitter-directmessage-source
spec:
  properties:
    key: value
    user: my-user
    password: just-provide-it-in-plain-text-for-now
  source:
    ref:
      apiVersion: camel.apache.org/v1alpha1
      kind: Kamelet
      name: twitter-directmessage
  sink:
    ref:
      apiVersion: messaging.knative.dev/v1alpha1
      kind: InMemoryChannel
      name: twitter

(edited after comment)

There are multiple reasons:

• The configuration I propose is compatible with the JSON schema exposed by the Kamelet definition (so it can be validated), while the array of configuration items is not
• We currently don't support per-property secret entries iirc, but only global secrets and it seems not easy to create them now, considering also that kamelet properties are locally scoped

Wdyt @lburgazzoli ?

[lburgazzoli]

We can but how do you define which secrets/configmaps the source need to mount ?

[nicolaferraro]

We can but how do you define which secrets/configmaps the source need to mount ?

Using a spec->integration field (same trick as in Knative CamslSources), until we figure out a better way to handle them.

[lburgazzoli]

so I guess this should be named properties instead of configuration to avoid confusion ? in that case yes we can use plain key/value pairs

[nicolaferraro]

A better format:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: twitter-directmessage-source
spec:
  source:
    ref:
      apiVersion: camel.apache.org/v1alpha1
      kind: Kamelet
      name: twitter-directmessage
    properties:
      key: value
      user: my-user
      password: just-provide-it-in-plain-text-for-now
  sink:
    ref:
      apiVersion: messaging.knative.dev/v1alpha1
      kind: InMemoryChannel
      name: twitter

They can be optionally used also in the sink part.

This removes the ambiguity about what endpoint the properties refer to.
Wdyt @lburgazzoli ?

[lburgazzoli]

LGTM, I think source and sink can be backed by the same struct at this point

[lburgazzoli]

btw, we can use the syntax:

password: #property:my-property-stored-in-a-secret

for sensitive info

[nicolaferraro]

btw, we can use the syntax:

password: #property:my-property-stored-in-a-secret

for sensitive info

Right! That can be done manually by the user.

[nicolaferraro]

LGTM, I think source and sink can be backed by the same struct at this point

Yes, I'm calling it "Endpoint", as we do in Camel ;)