nicolaferraro commented on pull request #2086: URL: https://github.com/apache/camel-k/pull/2086#issuecomment-789524867
> I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local kamelet repository (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run) I'm in favor of this solution for the short term, bundling the kamelets in the binary is useful to implement `kamel local bind`, but we agreed on making the CLI lighter and "version independent" in the future, so embedding kamelets goes against this. The local bind can be still implemented and require setting the repo location in advance. For the long run, an external image may be the solution. It can be shipped directly as release artifact of https://github.com/apache/camel-kamelets. But decoupling kamelet catalog version from operator version require more thinking, especially from an operational point of view. ---------------------------------------------------------------- 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
