0

When installing a helm chart directly (with helm 3), or using the helm provider in terraform, the same error is thrown which implies the download fails, something like:

Error: failed to download "https://agones.dev/chart/stable/agones-1.7.0.tgz" (hint: running `helm repo update` may help)

Running the repo update has no effect, nor does deleting the cache, trying a different release, different versions of Helm 3. However, wget (or similar) has no issue with fetching the chart, and the contents of the chart look correct, and even install when run as a local file rather than a remote download.

However, that cannot be used as a workaround in the case of something like the helm provider in terraform which expects a repository and will not accept file:// as a protocol for that definition. How to fix this permanently, and so that it "just works" again with terraform?

Adam C
  • 5,132
  • 2
  • 28
  • 49

1 Answers1

2

The error here is very difficult to debug in Terraform but the fact that it fails with a direct install allows for more information to be obtained, by adding a --debug flag to the command:

helm --debug install agones https://agones.dev/chart/stable/agones-1.7.0.tgz -n agones-system

Now the error is more verbose and the cause becomes obvious:

Error: no cached repo found. (try 'helm repo update'): open ~/.cache/helm/repository/local-index.yaml: no such file or directory

The local cache as defined in ~/.config/helm/repositories.yaml is missing. The likely reason for this is a helm v2 to v3 upgrade or perhaps a bug in the initial repo config, it can be fixed by creating the file as follows:

cp ~/.helm/repository/local/index.yaml ~/.cache/helm/repository/local-index.yaml

Once the file has been copied all helm operations should return to normal. If you don't have a copy of the file for whatever reason, it is very easy to create from scratch, here is what the contents of mine looked like:

apiVersion: v1
entries: {}
generated: "2020-07-14T18:21:24.471657624+01:00"

Just create the file manually with an appropriate timestamp and your errors should disappear.

Note: this was originally answered here (by me also), adding to ServerFault to help discoverability

Adam C
  • 5,132
  • 2
  • 28
  • 49