squakez opened a new issue, #5615: URL: https://github.com/apache/camel-k/issues/5615
### Requirement As soon as the work on #5610 is closed, we can retake the work previously discussed in #3865. However I'd like to suggest some change as, while working on #5610 I realized that Kustomize may not be the best option when it comes to a simple methodology to install that has similar capabilities to what we're used in `kamel install`. During these years we've worked adding a lot of flags to the `kamel install` in order to simplify the installation (ie, registry, maven repositories, build configs, ...). This was a very handy way to apply quickly configuration during the installation procedure as the user has to specify some parameter=value approach. Helm has a similar approach, as, it allows the chart to provide variables we can easily include in the Helm templating system and set those variables (ie, `helm install camel-k --set platform.build.registry.address=1.2.3.4`). It even allows the installation to stop if that value is not provided. Kustomize seems to be much more advanced as, conversely, requires the user to know exactly the Kubernetes resource to deal with. This could be a bit tricky, above all when we need to replace the CLI in the e2e tests. OLM, probably is something we cannot really use as a default, as, it also require managing the custom resource configuration for most of parameters. I'd like to hear any other pros and cons, so, we can try to work on this before next minor release. ### Problem a ### Proposal _No response_ ### Open questions _No response_ -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
