Eschewed features
What would you like to have added?
The feature flag --enable-helm works great for publicly accessible repositories but fails if a local chart is used which itself has other HELM dependencies like so:
apiVersion: v2
name: my-custom-chart
description: Custom chart to deploy Harbor and custom manifests
type: application
version: 0.1.0
dependencies:
- name: harbor
version: "1.18.3"
repository: "https://helm.goharbor.io"If you run helm dependency update or helm repo add + helm dependency build wherever the chart itself lives, everything works fine again. This is to be expected, since now kustomize is happy since it can easily resolve all dependencies again and can render the chart.
However, helm dependency update is a quite expensive operations and runs outside of kustomize itself (since it depends fully on HELM itself like --enable-helm already does). Therefore, this feature must be opt-in only.
Why is this needed?
The reason is simple - ArgoCD. If you use kustomize + HELM for a single ArgoCD project you will run into issues if your HELM chart has any dependencies. Using kustomize + HELM for single projects is desired in some cases since this allows for patching of otherwise inaccessible resources created by the chart, allows for better handling with sealed-secrets and might just be the intended way by some CI/CD teams to better keep track of rendered manifests. Ultimately, ArgoCD just runs kustomize build --enable-helm if it sees a kustomize.yaml file.
You could make a cases that this feature may be implemented into the ArgoCD project instead. However, by adding this feature into kustomize instead, it allows for other project which might use kustomize but not ArgoCD to also benefit from this.
Can you accomplish the motivating task without this feature, and if so, how?
Yes, but it is quite cumbersome. Here are some ideas on how this might be resolved:
- Fork the
kustomize repository, implement the feature yourself, create a custom ArgoCD Docker image which uses the custom kustomize binary instead and use that for your projects
- Create a custom config map in
ArgoCD which allows for "kustomized-helm" runs by providing a custom Docker image which has kustomize and HELM preinstalled which first runs helm dependency update and then runs kustomize build --enable-helm
- Simply commit the
chart folder containing the dependent charts into your repository (but this is not really best-practice)
What other solutions have you considered?
You could make the case for either using kustomize or HELM but not mixing them. However, for our specific use-case, we need both in conjunction. There simply isn't an alternative which does not introduce more management overhead.
Anything else we should know?
I have built a local PoC of this by adding the optional flag --helm-dependency-update which works if the flag --enable-helm is also present. If both flags are set, kustomize will simply run helm dependency update within all folders where a Chart.yaml is present. It works fine and does not introduce any breaking changes. Therefore, this won't impact any existing workflows / use cases.
Feature ownership
Eschewed features
What would you like to have added?
The feature flag --enable-helm works great for publicly accessible repositories but fails if a local chart is used which itself has other HELM dependencies like so:
If you run
helm dependency updateorhelm repo add+helm dependency buildwherever the chart itself lives, everything works fine again. This is to be expected, since nowkustomizeis happy since it can easily resolve all dependencies again and can render the chart.However,
helm dependency updateis a quite expensive operations and runs outside ofkustomizeitself (since it depends fully onHELMitself like--enable-helmalready does). Therefore, this feature must be opt-in only.Why is this needed?
The reason is simple -
ArgoCD. If you usekustomize+HELMfor a singleArgoCDproject you will run into issues if yourHELMchart has any dependencies. Usingkustomize+HELMfor single projects is desired in some cases since this allows for patching of otherwise inaccessible resources created by the chart, allows for better handling with sealed-secrets and might just be the intended way by some CI/CD teams to better keep track of rendered manifests. Ultimately,ArgoCDjust runskustomize build --enable-helmif it sees akustomize.yamlfile.You could make a cases that this feature may be implemented into the ArgoCD project instead. However, by adding this feature into
kustomizeinstead, it allows for other project which might usekustomizebut notArgoCDto also benefit from this.Can you accomplish the motivating task without this feature, and if so, how?
Yes, but it is quite cumbersome. Here are some ideas on how this might be resolved:
kustomizerepository, implement the feature yourself, create a customArgoCDDocker image which uses the customkustomizebinary instead and use that for your projectsArgoCDwhich allows for "kustomized-helm" runs by providing a custom Docker image which haskustomizeandHELMpreinstalled which first runshelm dependency updateand then runskustomize build --enable-helmchartfolder containing the dependent charts into your repository (but this is not really best-practice)What other solutions have you considered?
You could make the case for either using
kustomizeorHELMbut not mixing them. However, for our specific use-case, we need both in conjunction. There simply isn't an alternative which does not introduce more management overhead.Anything else we should know?
I have built a local PoC of this by adding the optional flag
--helm-dependency-updatewhich works if the flag--enable-helmis also present. If both flags are set,kustomizewill simply runhelm dependency updatewithin all folders where aChart.yamlis present. It works fine and does not introduce any breaking changes. Therefore, this won't impact any existing workflows / use cases.Feature ownership