Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate kamel install and change default installation to kustomize/helm/olm? #5615

Closed
squakez opened this issue Jun 11, 2024 · 1 comment · Fixed by #5657
Closed

Deprecate kamel install and change default installation to kustomize/helm/olm? #5615

squakez opened this issue Jun 11, 2024 · 1 comment · Fixed by #5657
Assignees
Milestone

Comments

@squakez
Copy link
Contributor

squakez commented Jun 11, 2024

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. Although we may think to just install via overlay and later change the IntegrationPlatform parameters by changing Kubernetes custom resources directly.

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.

@claudio4j
Copy link
Contributor

Perhaps an experimentation would be to change the kamel install of CI / e2e to either kustomize / helm and an open PR similar to the camel jbang experiment, to see thow that goes at first.
I'm not that familiar with kustomize, but helm seems pretty easy to customize the values, but when it comes with behavior we have to change the chart values for specific install conditions with those helm curly brackets, but that's the way it works.
The good part is either helm/kustomize are know to the community and easier to change customization by declaration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants