nicolaferraro commented on a change in pull request #1957: URL: https://github.com/apache/camel-k/pull/1957#discussion_r566918674
########## File path: proposals/provided-kamelets.adoc ########## @@ -0,0 +1,83 @@ +--- +title: Provided Kamelets +authors: + - "@nicolaferraro" +creation-date: 2020-01-29 +last-updated: 2020-01-29 +status: implementable +see-also: [] +replaces: [] +superseded-by: [] +--- + +[[provided-kamelets]] += Provided Kamelets + +== Summary + +As Apache Camel, we offer several components (300+) that can be used out-of-the-box in Camel K. Each one of them implements connection for a single +system/protocol and usually provides access to several features (hence the component configuration is usually over-complicated). +We also have defined the concept of Kamelet, that differently from a component, is an higher level resource and satisfies a single single use case and provides a +simple configuration. A Kamelet can also use one or more components in its definition, to make the distinction clearer. + +In parallel to the component catalog, I think it's a good idea to offer also a catalog of **"Apache Camel Kamelets"**. + +== Motivation + +There are several platforms that may benefit from a Kamelet Catalog that is embedded in Camel K: + +- The Knative team is https://github.com/knative-sandbox/kn-plugin-source-kamelet[thinking to integrate Kamelets into the `kn` CLI]: that plugin would query the +kamelets present in a Cluster and allow to instantiate sources from them. +- The OpenShift console https://github.com/openshift/console/pull/7344[has already merged support for Kamelets in next 4.7 release]: the console will display +Kamelets among available sources and allow users to configure them and bind them to a destination. +- Other platforms are encouraged to use the Kamelet model for ingress/egress use cases. + +As we move forward, we may want to build together a Catalog of curated Kamelets that people can leverage when using any platform that is powered by Camel K. + +== Goals + +- Involve the community into the creation of a Kamelet catalog, giving them means and examples on how to contribute new Kamelets and related tests, + to ensure we don't break them as we move forward. +- Make sure that when Camel K is installed on a cluster, tools and platforms can query the Kubernetes API to find installed Kamelets and use them. +- Make sure that Kamelets can be also used in `local run` executions. + +== Non-Goals + +- We don't want to auto-generate Kamelets from components, the Kamelet catalog should focus on common use-cases and grow with users needs. + +== Current state + +There's a procedure to embed Kamelets in the operator, but it's not used. + +The current implementation currently looks up Kamelets in the current namespace first, then in the operator namespace (in case it's different), then +it does a lookup on the `master` branch in https://github.com/apache/camel-kamelets to search for a specific Kamelet when used. +This causes problems because it's not difficult to hit rate limiting on using the Github APIs. There's a cache to avoid too many requests, but it's not always sufficient. + +== Proposal + +We should start to add Kamelets to https://github.com/apache/camel-kamelets, and help people contributing their own. Review comment: Yeah, I think we can find out some criteria considering the context of ingress/egress from a generic platform. But of course there's some more work to do. I.e. I think, after all, it would be acceptable to have a "beer-source" Kamelet provided by us. But is it also ok to provide a "chuck-source"? (I don't have the answer). These are just some concerns regarding publicly available APIs, but there are many others... ---------------------------------------------------------------- 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
