nicolaferraro opened a new issue #365: URL: https://github.com/apache/camel-k-runtime/issues/365
[Sinkbinding](https://knative.dev/docs/eventing/samples/sinkbinding/) allows to use an existing Camel K `Integration` as as a standard Knative source (it's listed among sources and compatible with the `kn` tools), without having to use the `CamelSource` object. To make the user experience good, there are some things to hammer here and there, but we can already enable them if we do some changes in the runtime. E.g. we can run an integration named `routes`, then provide the following sinkbinding: ``` apiVersion: sources.knative.dev/v1alpha1 kind: SinkBinding metadata: name: bind-camel-routes spec: subject: apiVersion: apps/v1 kind: Deployment name: routes sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display ceOverrides: extensions: sink: bound ``` It targets the underlying deployment created by the integration, but we can work to have also the Camel K Integration usable as `subject` in the future. The [contract](https://github.com/n3wscott/eventing/blob/master/docs/spec/sources.md#sinkbinding) of the `SinkBinding` spec says that information about the target endpoint will be injected in the following envs of the running pod: - K_SINK: target URL for sending cloud events (note that we already use `KNATIVE_SINK` to indicate the logical name of the sink in the loader, we can rename that to avoid confusion) - K_CE_OVERRIDES: header information to override We should configure the knative component to use those properties if available, before looking in the general config (or if there's no match there). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
