Please add support for chart mirrors (override dependency chart FQDN and base path)

[Speeddymon]

Output of helm version: irrelevant - affects all helm versions

Output of kubectl version: irrelevant - affects all kubernetes versions

Cloud Provider/Platform (AKS, GKE, Minikube etc.): irrelevant - affects all cloud providers

Hello! I have a need to install the public NewRelic helm chart in a cluster where GitHub has been firewalled off.

We have an internal repo which automatically proxies charts from GitHub. With a simple chart which has no dependencies, it's easy enough to just helm install <releasename> <internal repo chart path>. Doing so works great; our repo provider will go out to Github and download the chart into their repo and we can install the chart from there. However, for charts with dependencies that themselves are hosted publicly, the subchart URLs in the parent chart's Chart.yaml are kept in-tact, which leads to helm trying to reach out to Github for those subcharts despite the parent chart coming through our proxy.

At the moment, I've been unable to find a way to rewrite the chart URLs without forking the public parent chart, making the changes, packaging it and then uploading that to our internal repo via CI pipelines, so I thought I'd bring this here to ask if I've missed anything or if it would be possible somehow to support the use-case of overriding subchart URLs via command line flag? To be clear, what I've done works for now but I don't want to maintain an internal fork of a public chart.

I hope that maybe a CLI flag can be added in the future (also open to other solutions though!) to allow me to specify the base URL (at least the FQDN part and maybe a path prefix) to override where subcharts are pulled from at install/upgrade time. It could work similarly in function to how git's git config url.insteadOf works (simply overriding the normal url).

This would be great for helm to have and would satisfy my use-case perfectly. It doesn't need to be stored in a config file anywhere (values.yaml would definitely not be the right place, imho) -- so this could take the form in helm of helm install release_name parent_chart_path --url-insteadOf=github.com/some_path=my-repo.com/some_other_path/some_path --url-insteadOf=some-other-public-repo.com=my-repo.com which would need to be specified with each helm install or helm upgrade.

Here is an example of how it looks for git: https://gist.github.com/Kovrinic/ea5e7123ab5c97d451804ea222ecd78a#file-readme-md

Again I'm open to other ideas but this was what I thought of.

I'll add that I don't think it should be necessary to fork a public chart for internal use when we can proxy the parent chart itself; it defeats the purpose of helm being a package manager if I have to go make my own package; so helm should allow us to specify that the dependencies need to come from a different URL than the public URL. Nothing else is changing; it's a simple proxy. I could (and will) also ask our repo provider if they would consider adding some logic to their backend to catch this and mitigate it on their end, but I really feel that this should be done by Helm itself so that all of the community can benefit rather than each repo provider coming up with their own way to handle this.

Thanks in advance for your time and consideration.

[hegerdes]

I recently had the same problem and AFAIK there is no way to set/rewrite the dependency chart URLs.

As a workaround I ended up disabling all dependencies (this often works) and deploy every dependency as a separate install. Since I use ArgoCD it is not a problem to set up a source list of helm charts.

I think a list of configurable mirrors that can be passed to helm might be a solution

[Speeddymon]

Yes, you're correct there isn't a way to rewrite the URLs currently. The chart that we install is a sort of meta chart without any templates itself; so it exclusively depends on the other subcharts which have all of the templates.

Breaking out and installing each chart separately is a lot of extra overhead because NewRelic might add or remove subcharts in the future. Our automated solution solves for this by pulling the chart tarball through our proxy service and extracting it, then manipulating the dependencies field directly to change the FQDN and the initial part of the path en-masse and then repackaging it and uploading it.

Being able to configure mirrors directly with the helm command line would allow this meta chart able to be installed directly through our proxy service without the middle steps of pulling, extracting, modifying, packaging and uploading it. Additionally, CD tools like Flux and Argo could add support for this flag to allow them to accomplish the same thing.

I definitely agree support for repo mirrors is the right solution, and I'm updating the title of this issue now.

[github-actions[bot]]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[Speeddymon]

/remove-lifecycle stale

[Speeddymon]

Hello team, please remove the stale label. Thank you.

[github-actions[bot]]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[Speeddymon]

Hello, please remove the stale label.