[GitHub] [camel-k] nicolaferraro opened a new issue #639: [DISCUSS] Vision for Knative Sources

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org


With regards,
Apache Git Services