Terraform-provider-helm: Provider should set up a local environment

Created on 18 Sep 2017  ·  13Comments  ·  Source: hashicorp/terraform-provider-helm

The provider should configure $HELM_HOME (like helm init -c does). Without this, on an empty environment, I'm getting an error:

helm_chart.redis: open /home/mstrzele/.helm/repository/repositories.yaml: no such file or directory
enhancement

Most helpful comment

We are encountering the same issue with:

* helm_repository.articulate_helm: Couldn't load repositories file (/root/.helm/repository/repositories.yaml).

You might need to run `helm init` (or `helm init --client-only` if tiller is already installed)

We run terraform via docker, which means that the local filesystem is destroyed every time we re-run terraform. If helm init is required to be able to use the helm_repository than it feels like that is something that the provider should do.

provisioner / local-exec doesn't work because that only runs on creation or destroy, and won't exist when it goes to refresh the repository info.

Not sure what the correct course of action here is.

All 13 comments

This might be a little bit trickier than I thought it is.

The repositories.yaml file is created and stored outside the Terraform state, therefore, when the second run of any configuration that uses the Helm provider is done (in a clean environment), the repositories.yaml file is empty or missing and it won't be regenerated since any helm_chart nor helm_repository wasn't changed.

I attempted to work around this by using a relative path home directory and committing it in git, but found an issue with that https://github.com/kubernetes/helm/issues/2975.

After the discussion there, I think perhaps this issue should be limited to "when no home directory is configured".

Until that bug is fixed and pulled in, my next thought is to add a tarball of a working ~/.helm for my CI system and use an environment variable in tandem with a local-exec to unpack it into place.

And, local-exec, of course, won't work during a plan run. I think the relative path home directory would work since I can at least keep those files in sync.

https://github.com/rprobotics/helm/pull/1 makes the home attribute work just fine. 🙌

I assume this has been resolved and can be closed?

@jhoblitt I haven't seen any changes related to this in the provider. I'm still trying to get my (modified) patches merged into upstream helm to make the home directory portable, though I think that will happen in time for helm 2.9.0.

I'm not seeing the original error message reported with stable/redis but I haven't checked to see if repositories.yaml is updating.

I've try to set env with HELM_HOME =~/.helm-home/
without any success
I still have this king of message :
`
*helm_repository.projectriff: 1 error(s) occurred:

*helm_repository.projectriff: Couldn't load repositories file (~/.helm-home/repository/repositories.yaml).
You might need to run helm init (or helm init --client-only if tiller is already installed)
`

With the latest version of this provider I was able to use a relative HELM_HOME and run it in CI. In my CI configuration I set HELM_HOME=./.helm_home and I created .helm_home/repository/repositories.yaml with the contents

apiVersion: v1
generated: 2018-09-21T13:36:10.98821334+02:00
repositories: []

This works because we specify the repository URL for all our releases, although of course you could set actual repositories in here. I'm not sure how the interaction with the helm_repository resource would work. I imagine you'd have to try to keep that in sync with whatever you check into Git. Not setting any repositories lends itself better to GitOps/CI+CD workflows IMO.

We are encountering the same issue with:

* helm_repository.articulate_helm: Couldn't load repositories file (/root/.helm/repository/repositories.yaml).

You might need to run `helm init` (or `helm init --client-only` if tiller is already installed)

We run terraform via docker, which means that the local filesystem is destroyed every time we re-run terraform. If helm init is required to be able to use the helm_repository than it feels like that is something that the provider should do.

provisioner / local-exec doesn't work because that only runs on creation or destroy, and won't exist when it goes to refresh the repository info.

Not sure what the correct course of action here is.

@tecnobrat the thing is that helm init is not idempotent, because it will grab the repositories at the time it is being invoked. Therefore I think it is more idiomatic to check your repositories file ($HELM_HOME/repository/repositories.yaml) into the repo and set HELM_HOME appropriately in your Dockerfile and/or CI environment configuration.

Closing this issue since is making reference to a version based on Helm 2, if this is still valid to the master branch please reopen it. Thanks.

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kim0 picture kim0  ·  12Comments

iliasbertsimas picture iliasbertsimas  ·  12Comments

dangarthwaite picture dangarthwaite  ·  19Comments

obeyler picture obeyler  ·  16Comments

alexkreidler picture alexkreidler  ·  71Comments