Support Knative Sinks

[lburgazzoli]

https://knative.dev/docs/eventing/sink/

[lburgazzoli]

@christophd maybe you are interesting in this ?

[christophd]

@lburgazzoli sure!

but isn't this covered already by Kamelets?

[lburgazzoli]

could be :) I wonder if there is anything missing like the creation of a SinkBinding & role binding

[christophd]

So in terms of an eventing source a KameletBinding defines a Kamelet as a binding source and a channel/broker as a sink within the binding. This approach has replaced the former CamelSource in knative eventing.

In terms of an eventing sink another KameletBinding is able to act as a Knative eventing sink by using a Knative channel/broker as a source and a Kamelet as a sink within the binding.

So sources/sinks are represented through KameletBindings with Knative resources (channel/broker) being a part of the binding as a source or sink.

[lburgazzoli]

ok, so there's nothing that needs to be done right ? if so, we can close this issue

[christophd]

we are not able to use a Knative Trigger directly in a KameletBinding in order to filter the events that are consumed by the sink. We need to have a channel that the KameletBinding uses to consume events. That's the only difference I see at the moment.

in general it is a different approach compared to that one used by Knative SinkBinding. if we are ok with that

[lburgazzoli]

talking aloud: wonder if we can add an additional option to the knative trait so that when it creates a sink, instead of using a channel we just publish a service with the relate k8s Service so that it would become addressable ?

[christophd]

sounds like a valuable option

[astefanutti]

talking aloud: wonder if we can add an additional option to the knative trait so that when it creates a sink, instead of using a channel we just publish a service with the relate k8s Service so that it would become addressable ?

IIUIC, this is already done, as a KnativeService is created that's addressable (when the integration exposes an HTTP endpoint).

I wonder whether that'd make sense the integration to be addressable so that it can be a Sink target?

Currently, sinking to an addressable resource from the integration is supported, and a SinkBinding resource is automatically created when there is something like to(knative:endpoint) or to(knative:channel). Maybe it could be useful to support sinking directly into an integration...

[astefanutti]

I've just stumbled upon #1122, that is about making integrations addressable.

[lburgazzoli]

Yeah, I think we have all the building blocks, however I wonder if we need to add something more to make KameletBindings for sinks a little more declarative, as example my understanding is that as today, to create a sink with a binding we have to do something like that:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: telegram-sinlk
spec:
  source:
    ref:
      kind: InMemoryChannel
      apiVersion: messaging.knative.dev/v1
      name: messages
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: telegram-text-source
    properties:
      botToken: the-token-here

But as Christoph said, this is limited to channels so I wonder if we can have a more declarative way of expressing the source, like

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: telegram-sink
spec:
  source:
    ref:
      kind: Service
      apiVersion: serving.knative.dev/v1
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: telegram-text-source
    properties:
      botToken: the-token-here

So in essence, this would create a knative service named telegram-sink backed by the camel-knative component. Of course this may be done by using a kamelet as source but wonder if it would make sense to directly use knative resources

[christophd]

I like the idea to auto create the knative service resource telegram-sink as part of the KameletBinding. Feels more natural and makes the usage of the channel obsolete.

It would be good to also auto create the respective knative trigger for the service (with filter on events that should be consumed by the KameletBinding)

[github-actions[bot]]

This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!

[squakez]

Maybe we should not let it closed yet. @christophd can you confirm if it makes sense to keep it open and never stale?

[christophd]

@squakez @lburgazzoli after another review of the current capabilities I think we can close this issue as completed. With the opportunity to use the Knative broker event stream as a source with optional filtering on CloudEvents attributes this can be considered as done already

apiVersion: camel.apache.org/v1
kind: Pipe
metadata:
  name: knative-log-sink
spec:
  source:
    ref:
      kind: Broker
      apiVersion: eventing.knative.dev/v1
      name: default
    properties:
      type: org.apache.camel.event.messages
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1
      name: log-sink

[lburgazzoli]

I thin one missing point could be related to the make integrations addressab issue ?