kustomize downloads helm charts and then reuses them when new version specified

[justinsb]

What happened?

I believe this issue has come up a few times, but I think there is a very concrete incorrect behaviour bug that I think we can & should fix. (I'm happy to work on fixing it if need be).

I was using the helmCharts support, with an upstream cilium chart, version 1.12.5. When I run kustomize, it automatically downloads the cilium chart into ./charts/cilium-1.12.5.tar.gz, and inflates it into ./charts/cilium.

I then change the chart version to 1.13.1, but kustomize continues to use ./charts/cilium, which is version 1.12.5

What did you expect to happen?

I would expect it to use the version I specified, given I didn't directly populate ./charts/cilium (if I had created that directory myself, maybe the behaviour would be more understandable)

How can we reproduce it (as minimally and precisely as possible)?

# kustomization.yaml
helmCharts:
- name: cilium
  repo: https://helm.cilium.io/
  version: 1.12.5
  releaseName: cilium
  namespace: kube-system
  valuesInline:
    hubble:
      enabled: false

Run kustomize build, change the version, the old version is used.

Expected output

No response

Actual output

No response

Kustomize version

main

Operating system

Linux

[justinsb]

Currently helm downloads a helm chart every time it is used.

There's an upstream helm "KEP" where they talk about using a content cache: https://github.com/helm/community/pull/185/files

I think a simple fix here could be to download into a temporary directory and not cache it. That is consistent with the helm behaviour (until the helm KEP is approved / implemented):

Helm cannot use the chart version in the cache because the identifier is the name and charts version (e.g., wordpress-1.2.3.tgz). A name and version is insufficient as the same chart and version could come from two or more different repositories and have different content.

Although we could implement our own mechanisms here for more efficient caching / verification (there is a digest in the index.yaml), I suggest that should instead be done in helm (first), we don't want to build something incompatible.

[justinsb]

Looks like there's even a PR that is a good starting point: #4999 , though I think we should first agree the behaviour (and maybe I should just be using the KRM function instead?)

[natasha41575]

Thanks for pointing out #4999! We must have missed it.

@justinsb Do you have time to give it a quick review? I will find some time to review it as well.

Re: the KRM function, kustomize functions aren't quite mature enough to be the recommended solution, but it is our desired end goal some day.

[natasha41575]

@justinsb This seems to be a duplicate of #4813 it seems, which I acknowledge is old, but I think we can consider it still active. Do you have any concerns with closing this issue and using #4813 to track the work?

[ChristianCiach]

Also a duplicate of #3848 (issue by me)

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.