You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: