Per-chart chartHome in kustomization.ayml

[mkoval]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Add a chartHome property to the each entry in helmCharts, which overrides the global helmGlobals.chartHome property when present.

For example, the following should be possible:

helmCharts:
- chartHome: path/to/my/repo1_name
  name: chart1_name
- chartHome: path/to/my/repo2_name
  name: chart2_name

Why is this needed?

First, the current way of specifying this parameter (described below) is confusing. The URL to a remote repositories are specified by helmCharts[*].repo. The path to a local repository is specified by helmGlobals.chartHome, which is in a different YAML map and is specified differently than when manually configuring HelmChartInflationGenerator via an external YAML file.

Second, it status quo makes it difficult to install local charts from more than one directory because helmGlobals.chartHome is global. There is a workaround, but it is non-obvious and complicates kustomization.yaml by requiring the creation of a separate YAML file for each chart. I also not sure if this way of instantiating not even sure if this way of instantiating HelmChartInflationGenerator is supported, since I was unable to find any reference to this way of instantiating it in the Kustomize documentation.

Can you accomplish the motivating task without this feature, and if so, how?

Yes, but it is awkard. HelmChartInflationGenerator can install a Helm chart at the relative path path/to/my/repo_name/chart_name with the following configuration:

helmGlobals:
 chartHome: path/to/my/repo_name/
helmCharts:
- name: chart_name

This works if all helmCharts entries in kustomization.yaml share the same parent directory because chartHome is shared by all charts in the file. The solution is more complex if you need to install Helm charts from multiple repositories.

The workaround is to create a separate HelmChartInflationGenerator instance for each chart you want to install, then reference them in kustomization.yaml:

generators:
- repo1_name-chart1_name-generator.yaml
- repo2_name-chart2_name-generator.yaml

Here is an example of what one of the -generator.yaml files might contain.

apiVersion: builtin
kind: HelmChartInflationGenerator
metadata:
  name: repo1_name_chart1_name
chartHome: path/to/my/repo1_name
name: chart1_name

This works because HelmChartInflationGenerator allows chartHome to be specified on a per-chart basis, unlike kustomization.yaml where it is global for the entire file.

What other solutions have you considered?

The status quo. While it is possible to workaround the lack of this feature, I don't think this is a good solution. It might take more effort to document the workaround and educate users than to make the configuration more intuitive.

Use the existing repo field in helmCharts. If the value is a file:// or local path, it could be interpreted as a chartHome override rather than a remote URL. This is arguably a better solution because it eliminates the (confusing) distinction between local and remote repositories. However, it would be tricky to get the parsing exactly right. Any bugs in the parsing logic could prevent a user from installing a remote chart.

Anything else we should know?

This led myself and several others to erroneously believe that HelmChartInflationGenerator did not support installing from a local repository in #4378.

I would expect most users of ArgoCD or Flux who use Kustomize to eventually run into this problem. It is common to have Helm charts from multiple repositories. It is also common to have a maintain cache of a Helm repository to avoid network, permission, and versioning issues.

Feature ownership

• I am interested in contributing this feature myself! 🎉

I have not contributed to Kustomize before -- so I am unfamiliar with the development environment and submission process. I am open to learning and taking a stab at imlpementing this myself, if is not too difficult to ramp up.

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.