Terraform-provider-helm: Getting helm repository not found error on running a subsequent terraform apply during refresh state

Created on 5 Dec 2018  路  11Comments  路  Source: hashicorp/terraform-provider-helm

Terraform Version


Terraform v0.11.10

Affected Resource(s)

  • helm_repository

Terraform Configuration Files

resource "helm_repository" "helm_repo" {
  name = "my-helm-repo"
  url  = "<url here>"
}

Debug Output

Panic Output

Expected Behavior


Running a subsequent terraform apply without any changes should refresh the state correctly for helm_repository

Actual Behavior


Error: Error refreshing state: 1 error(s) occurred:

  • helm_repository.services_repo: 1 error(s) occurred:

  • helm_repository.ervices_repo: helm_repository.services_repo: repository not found

Steps to Reproduce

  1. Run terraform apply with a helm_repository resource
  2. Run terraform apply again

Something to note, I change workspaces and use terraform workspaces for my environments (i.e. dev, qa, prod) not sure if that would affect how the helm repo state gets refreshed

Important Factoids

References

  • GH-1234

Most helpful comment

All 11 comments

The fixes proposed by @divoxx in the two prs mentioned here https://github.com/terraform-providers/terraform-provider-helm/pull/137 would solve this

I understand the changes were reverted and the PR was rejected because it isn't the "terraform way". But in the current state functionality is broken.

I would think fixing this release using the Exists provider is a acceptable stopgap until the helm_release is updated to download the charts

For what it's worth. using the latest release from @divoxx does fix the problem. Unfortunately terraform doesn't provide a great way to auto init 3rd party plugins so this hopefully can be up streamed soon

Any news on this?

We are facing the same issue.
A work around seems to be adding the helm repo beforehand and to completly omit the repository on the helm_release part.

@Rowern I'm using the forked PR that @divoxx made to build the provider.

My personal workaround is to have a null_resource which runs a helm repo add <url> and uses a hacky triggers = { ts = "${timestamp()}" } which forces the command to be run on every terraform invocation.

We've the same issue here and are applying this locally. Thanks for the workaround mentioned!

fwiw this is solved with the data provider so I believe this can be closed

I've switched to using the data provider from helm provider v0.9.0 as well

@cpoole @btai24 Could you please elaborate on the "data provider"?

I have

data "helm_repository" "jetstack" {
  name = "jetstack"
  url  = "https://charts.jetstack.io"
}

and

resource "helm_release" "cert_manager" {
  name       = "cert-manager"
  repository = "${data.helm_repository.jetstack.metadata.0.name}"
  chart      = "cert-manager"
  version    = "0.7.0"
  namespace  = "cert-manager"
...

and if I comment out the workaround that @marcelloromani mentioned (running helm repo add <url> using a null_resource), terraform apply still errors out with

Error: Error applying plan:

1 error(s) occurred:

* helm_release.cert_manager: 1 error(s) occurred:

* helm_release.cert_manager: repo jetstack not found

Thanks in advance

Out of curiosity, do you have multiple helm_repository blocks? I'm working through an issue right now that seems to be that if you have multiple, the repositories.yaml will keep getting overwritten so effectively only one repository is added.

Yes, I do have multiple helm_repository blocks, specifically these two

data "helm_repository" "stable" {
  name = "stable"
  url  = "https://kubernetes-charts.storage.googleapis.com"
}

data "helm_repository" "jetstack" {
  name = "jetstack"
  url  = "https://charts.jetstack.io"
}
Was this page helpful?
0 / 5 - 0 ratings