You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll start tracking here work for Knative sources. Here I'd like to discuss the vision for the future.
Apart from what we've today, I'd like to expand the features offered in the Knative area in two directions.
OOB Sources
This is the continuation of the work done so far. We can currently create sources corresponding to Camel components, but there's only one definition of source called CamelSource that can be customized using different URIs and properties.
This effort will continue with generating automatically specific CamelSource definitions per component, that can be used OOB by people that don't know anything about Camel. E.g. we'll create a CamelKafkaSource definition, a CamelTelegramSource definition, and so on.
Those sources will be translated into a CamelSource under the hood. This means that the current Camel Knative controller will be turned into a "meta-controller".
Camel K Sources
There are many use cases that are not solved by the first kind of sources. Those include sources that may need multiple interactions with enterprise systems and custom transformations before being able to push events to a Knative endpoint.
As long term evolution of this approach, I'd like to see the possibility to create CamelKSource definitions using the kamel CLI.
As we do now kamel run it.groovy to run an integration, we may want to add a similar command like kamel create source it.groovy to generate a Knative-compatible source definition.
A knative source definition can be installed in a cluster and acts as a integration template. Once people fill-in the required properties, the corresponding source can be executed by Camel K.
The long term scenario should be something like:
I've some systems for which I want to provide a connector for Knative
I create the connector to my system using Camel K
I generate the resources that bind Knative to my system using kamel
Users can deploy those resources to Kubernetes and just use them
If my system is interesting for others, I can also publish my connector to a marketplace (it can be OperatorHub)
Only developers need to know Camel K, users of a connector can just use it.
The text was updated successfully, but these errors were encountered:
I'll start tracking here work for Knative sources. Here I'd like to discuss the vision for the future.
Apart from what we've today, I'd like to expand the features offered in the Knative area in two directions.
This is the continuation of the work done so far. We can currently create sources corresponding to Camel components, but there's only one definition of source called CamelSource that can be customized using different URIs and properties.
This effort will continue with generating automatically specific CamelSource definitions per component, that can be used OOB by people that don't know anything about Camel. E.g. we'll create a CamelKafkaSource definition, a CamelTelegramSource definition, and so on.
Those sources will be translated into a CamelSource under the hood. This means that the current Camel Knative controller will be turned into a "meta-controller".
There are many use cases that are not solved by the first kind of sources. Those include sources that may need multiple interactions with enterprise systems and custom transformations before being able to push events to a Knative endpoint.
For those use cases, I'm working on adding support for generic Camel K integrations to be used as CamelSource (https://github.com/nicolaferraro/eventing-sources/blob/camel-k-2/contrib/camel/samples/source_camel_k.yaml).
As long term evolution of this approach, I'd like to see the possibility to create CamelKSource definitions using the
kamel
CLI.As we do now
kamel run it.groovy
to run an integration, we may want to add a similar command likekamel create source it.groovy
to generate a Knative-compatible source definition.A knative source definition can be installed in a cluster and acts as a integration template. Once people fill-in the required properties, the corresponding source can be executed by Camel K.
The long term scenario should be something like:
kamel
Only developers need to know Camel K, users of a connector can just use it.
The text was updated successfully, but these errors were encountered: