nicolaferraro opened a new issue #639: [DISCUSS] Vision for Knative Sources
URL: https://github.com/apache/camel-k/issues/639
 
 
   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.
   
   1. 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".
   
   1. 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.
   
   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 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.

----------------------------------------------------------------
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:
[email protected]


With regards,
Apache Git Services

Reply via email to