terraform-provider-helm: Error: cannot re-use a name that is still in use

I had the same problem, and after exploring all kinds of resources in k8s, I found a secret “sh.helm.release.v1.spa-demo.v1” that had been left behind after a partial deployment of my app “spa-demo” with a crashing container. I had to examine every resource I could think of to look for left behind resources from the failed deploy and remove them manually. Found most of them quickly, but the secret was easy to miss and also the service account.

Same here… I started with helm list and then tried to find objects… Remember to use the appropriate namespace…

• Deleted deployment, found secret

$ helm list -n kube-system
NAME        	NAMESPACE  	REVISION	UPDATED                             	STATUS  	CHART             	APP VERSION

$ kubectl get deployments -n kube-system
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
coredns        2/2     2            2           92m
external-dns   0/1     1            0           3m47s

$ kubectl delete deployment -n kube-system external-dns
deployment.apps "external-dns" deleted

$ kubectl -n kube-system get secrets | grep helm
sh.helm.release.v1.external-dns.v1               helm.sh/release.v1                    1      2m54s

$ kubectl delete secret sh.helm.release.v1.external-dns.v1 -n kube-system
secret "sh.helm.release.v1.external-dns.v1" deleted

• Everything worked again re-running terraform apply

I ran into that a couple of times … usually it relates to a terraform run that was interrupted or something similar … as far as I know helm creates secrets to keep track of the version of a deployment … as @dniel and @marcellodesales already mentioned deleting release related resources - most times it’s just the sh.helm.release.v1.MYRELEASENAME.v1 secret in target namespace - will solve the problem … not sure if this is actually an open bug (anymore) 🤔 … one might state it’s a known behavior by now 😉)

This happens on a newly built cluster, too. I suspect this is more of a helm shenanigans rather than tf provider which merely leverages helm.

Not sure if it can help, but I just had the same error when the AWS Token expired in the middle of an apply (sigh).

Terraform: v0.14.8 helm_provider: 1.3.2 helm: 3.5.3

I found this that solved: https://github.com/helm/helm/issues/4174#issuecomment-605485703

With Helm 3, all releases metadata are saved as Secrets in the same Namespace of the release. If you got “cannot re-use a name that is still in use”, this means you may need to check some orphan secrets and delete them

kubectl -n ${NAMESPACE} delete secret -lname=${HELM_RELEASE}

workaround is definitely as stated in previous comment:

search and delete all related helm resource by name: secrets, services, deployments, etc.

This helped us find all the resources attached to a specific Helm release (source):

kubectl get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm,app.kubernetes.io/instance=release-name'

Please can we update the provider to list exactly what resources it is conflicting with, it took ages to figure out that it left over some secrets from a botched rollout.

When looking for resources left behind it might be handy to make use of the labels Helm uses.

kubectl get all -A -l app.kubernetes.io/managed-by=Helm shows you all the resources created by helm

The possible solution to import that existing release to terraform state $ terraform import helm_release.example default/example-name. https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#import

This provider seems unusable because of this issue.

I bumped into the error after cancelling a previous run (the cloud provider stack on fulfilling a PVC request). That left some orphan resources (svc,cm,sa,…), after deleting them I could re-run the apply just fine.

I think it’s worth pointing out that, at least from my perspective, this boils down to the provider’s behavior being non-intuitively different than the helm CLI.

If I’m using the CLI directly, it is safe, normal, and entirely expected to do something approximating:

helm upgrade --install --atomic mychartinstall myrepo/mychart

And in nearly all possible states of the chart on the cluster (not yet installed, fully installed, installed but some resources missing/deleted) helm will attempt to bring the chart up to the latest version and create all of the chart’s resources.

But as far as I can tell, there is no way to approximate this behavior with the helm provider. It is, effectively, running helm install rather than helm upgrade --install, and if there is no record of the chart in terraform state but there are any helm metadata secrets present on the cluster (for example if a CI/CD system has installed the chart before terrform ran, or if a previous terraform run failed without the atomic option being set), you will get the “Cannot re-use a name that is still in use” error.

I’m going to work up a pull request to address this, but it would be good to know in advance if the maintainers here have an opinion about what kind of approach they’d like to see: a set of attributes to the helm_release resource that lets the user specify “upgrade” behavior, or a new resource since this is a fairly different use case. (Absent any direction I’ll try the former.)

Also it would be nice to know if this provider is going to stay MPL-licensed or if it also is going to be re-licensed under the BSL, as my interest in contributing in the latter case is strictly zero.

It happens for me after timeout / auth failure againt K8S API during Helm processing.

However, taking a look at release state is properly displayed in pending-install. So even if it won’t unblock, Helm Terraform provider shouldn’t report a re-use issue but a pending one.

You still have to manually uninstall (for first release) or rollback but still provide a clear explanation of the situation and let you know remediation process instead of letting you in darkness …

So, I was feeling a little motivated…

https://registry.terraform.io/providers/n-oden/helm/latest

This is a fork from the current head commit of terraform-provider-helm, with https://github.com/hashicorp/terraform-provider-helm/pull/1247 applied to it. It is not my intention to maintain a long-lived fork of the provider, but given that hashicorp is notoriously slow at reviewing external PRs, I figured it might be useful to some of the people who have commented in this issue: if you find that it addresses your use case, please 👍 the pull request!

The TLDR is that you can enable idempotent installs that are safe against several of the failure modes described in this issue by adding an upgrade block to the resource:

upgrade {
  enable  = true
  install = true
}

This triggers behavior that is, as close as I can make it, identical to running helm upgrade --install myreleasename repo/chart using the helm CLI: the release will be installed if it is not there already, but if it is, helm will attempt to “upgrade” it to the configuration specified in the resource and then save the results in terraform state. This should be proof against situations where either a previous run of the provider was interrupted in a way that prevented cleanup, or where an external system (e.g. CI/CD) has installed the release before terraform could be run.

Use this entirely at your own risk, and only after reading the documentation and ideally the pull request itself to understand the behavior being enabled. Using this in a production environment before any of the actual provider maintainers have commented is emphatically not recommended-- even if the PR is eventually merged, the semantics (and hence the saved state) might change during the review process.