helm: helm install --replace fails with "cannot re-use a name that is still in use"

Hi, I try to idempotently deploy a package with:

helm install --replace --tiller-namespace=system --namespace=system -n somepackage

(I use the system namespace, and tiller is deployed into it, so no mistake there), but the second time it fails with

"Error: cannot re-use a name that is still in use"

The first install runs flawless, it’s the subsequent ones that fail. I am using helm version:

Client: &version.Version{SemVer:"v2.7.0-rc1", GitCommit:"1eff362941a349ab577c356f037ee093b23767a7", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.0-rc1", GitCommit:"1eff362941a349ab577c356f037ee093b23767a7", GitTreeState:"clean"}

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 29
Comments: 48 (9 by maintainers)

Commits related to this issue

#3134 Document how to update a deployment idempotently To use the same command when installing and upgrading a release, using helm upgrade with --install works. — committed to splisson-altair/helm by splisson-altair 7 years ago
#3134 Document how to update a release idempotently To use the same command when installing and upgrading a release, using helm upgrade with --install works. — committed to splisson-altair/helm by splisson-altair 7 years ago
docs(helm): Document how to update a release idempotently To use the same command when installing and upgrading a release, using helm upgrade with '--install' works. Closes #3134 — committed to splisson/helm by splisson 7 years ago
docs(helm): Document how to update a release idempotently (#3148) * docs(helm): Document how to update a release idempotently To use the same command when installing and upgrading a release, using... — committed to helm/helm by splisson 7 years ago
When checking for "name reuse", consider SUPERSEDED deploys as valid. Relates to #3134, but does not fix the underlying cause of releases ended up stuck in SUPERSEDED. Also cleans up the boolean logi... — committed to atombender/helm by atombender 6 years ago

Most upvoted comments

workaround: helm upgrade --install

+204

splisson-altair on Nov 13, 2017

I strongly recommend running all charts through helm template and then taking the output through kubectl apply --dry-run, which acts as a linter. This is how I discovered the problem; we have an internal tool that wraps Helm and does this automatically now.

+13

atombender on Apr 19, 2018

@technosophos Any progress on this? It’s hitting us in production, where we can’t just helm del --purge stuff that in use, like statefulsets that need to be carefully managed.

I did notice that when the problem happens, it seems that every upgrade has been SUPERSEDED, except the last one, which was DEPLOYED, e.g.:

38      	Tue Mar 20 22:57:40 2018	SUPERSEDED	elasticsearch-0.0.1	Upgrade complete
39      	Wed Apr  4 16:46:39 2018	SUPERSEDED	elasticsearch-0.0.1	Upgrade complete
40      	Wed Apr  4 16:49:04 2018	SUPERSEDED	elasticsearch-0.0.1	Upgrade complete
41      	Wed Apr  4 21:34:46 2018	SUPERSEDED	elasticsearch-0.0.1	Upgrade complete
42      	Wed Apr  4 21:36:40 2018	DEPLOYED  	elasticsearch-0.0.1	Upgrade complete

I don’t understand why they would differ in status. These have all been done with helm upgrade --install.

atombender on Apr 5, 2018

I’m getting this on a lot of deploys now. Until this is fixed, is there a temporary workaround aside from helm delete --purge?

atombender on Mar 29, 2018

Another workaround is to delete the corresponding namespace and then create a new one. For example deleting the namespace kuberhealthy:

helm ls --all-namespaces
kubectl delete namespace kuberhealthy
kubectl create namespace kuberhealthy

GoingMyWay on Mar 8, 2022

I’ve noticed a couple of times now that the error shows up if I have something invalid (e.g. reference to a variable that has a typo) in the chart, and goes away if I fix the error. It looks a lot like Helm is masking the underlying linting error, and emitting the cannot re-use error instead. I didn’t realize this earlier because the workflow was using did not lint the charts before running helm.

atombender on Apr 10, 2018

I keep running into this issue.

helm upgrade --install works for me, but actually I need to use helm install --replace, because I want to fully reset my installations for review environments.

I read a lot of comments that this error really just hides a template issue, but I don’t think this is the issue for me, since helm upgrade --install works.

Is helm install --replace really broken or could there be something wrong with my own setup after all?

helm install --replace worked for me

makhijamanish on May 21, 2020

I keep running into this issue.

helm upgrade --install works for me, but actually I need to use helm install --replace, because I want to fully reset my installations for review environments.

I read a lot of comments that this error really just hides a template issue, but I don’t think this is the issue for me, since helm upgrade --install works.

Is helm install --replace really broken or could there be something wrong with my own setup after all?

remcohaszing on Jul 3, 2019

I also ran into the masking problem. Is it possible to fix it and make Helm show the actual problem in the error message.

elchtestAtBosch on Nov 8, 2018

@technosophos Can we please reopen this? The issue still exists on 2.9.0.

As an aside, I have noticed that sometimes this error occurs even when the manifests don’t contain any syntactical or semantic errors. However, since Helm is masking the underlying error, there’s no way to tell what’s preventing the deploy from working. All that is in Tiller’s log is:

[tiller] 2018/05/04 15:22:57 getting history for release elasticsearch-production
[storage] 2018/05/04 15:22:57 getting release history for "elasticsearch-production"
[tiller] 2018/05/04 15:22:58 preparing update for elasticsearch-production
[storage] 2018/05/04 15:22:58 getting deployed releases from "elasticsearch-production" history
[storage] 2018/05/04 15:22:58 getting last revision of "elasticsearch-production"
[storage] 2018/05/04 15:22:58 getting release history for "elasticsearch-production"
[storage] 2018/05/04 15:22:58 getting release history for "elasticsearch-production"
[tiller] 2018/05/04 15:22:59 failed update prepare step: cannot re-use a name that is still in use

atombender on May 4, 2018

Thumbs up to @atombender for the tip. Helm really is misleading with the error message. My underlying chart template evaluated to a Yaml with indententation errors and helm spits out this exact message:

Error: UPGRADE FAILED: cannot re-use a name that is still in use

Fixing my chart template got rid of the problem. Thank God I can helm template to view the processed yaml created by the template to check for errors.

juliohm1978 on Apr 19, 2018

Ah, yes, tnx. I saw that somewhere. Which is the real problem: where can I read about deploying helm packages idempotently with the same command. It’s not in the documentation.

Is anybody reading this with the know how to edit the docs about this? I suspect ppl are losing time finding out about this, like me.

Morriz on Nov 13, 2017

It turns out to be a template error, as indicated above, but the message was masked until I ran helm delete --purge.

27Bslash6 on May 9, 2018

We also got the same Error: UPGRADE FAILED: cannot re-use a name that is still in use and we have to delete the release and recreate again.

It would be more helpful if we get the error message because of which this is failing.

worldofprasanna on Apr 24, 2018

I don’t even know what’s causing it. What is happening that’s making it consider a name to be “in use”?

On Apr 5, 2018, at 01:59, Matthew Fisher notifications@github.com wrote:

I’m sorry! We simply haven’t had the time to look into your issue in particular. If you have a patch, we’d happily look into it. 😃

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

atombender on Apr 5, 2018

Deleting the namespace isn’t an option if this happens on the default namespace. I’m having a similar issue where my helm install returned an error and then helm uninstall also errored. Now the release is gone but Helm seems to think it’s still there.

samos123 on Nov 1, 2023

Is this issue still present on more recent versions of Helm 2 (e.g. 2.14.3)?

@juliohm1978 what would you suggest we change the title to?

bacongobbler on Aug 14, 2019

^ Agreed. This issue is still present and still a problem that I have to workaround on a regular basis by deleting and redeploying released.

It’s also not a support question, this is a bug.

27Bslash6 on Apr 18, 2019

I’m still getting this error on Helm 2.9.1:

$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

I’m using the following chart - https://github.com/so0k/flask_app_k8s/tree/master/chart/flask-app

How to reproduce:

$ helm upgrade --install --set image.tag=master test chart/flask-app/
Release "test" does not exist. Installing it now.
NAME:   test
LAST DEPLOYED: Mon May 28 18:21:34 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME            DATA  AGE
test-flask-app  1     0s
...

Running helm upgrade with --reuse-values flag hits this error

$ helm upgrade --force --reuse-values --timeout 300 test chart/flask-app/
Error: UPGRADE FAILED: cannot re-use a name that is still in use

But without the --reuse-values flag, there is no error

$ helm upgrade --force --timeout 300 test chart/flask-app/
Release "test" has been upgraded. Happy Helming!
LAST DEPLOYED: Mon May 28 18:22:40 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME            DATA  AGE
test-flask-app  1     1m
...

I downgraded to Helm 2.8.2 and it works

so0k on May 28, 2018

Adam and I found a regression that might have led to @27Bslash6 's particular version of this problem. I don’t know if it’s the same that @atombender is hitting. But the validation logic got broken during the Kubernetes 1.9 API update, and that would have led to the apparent naming conflict on an invalid template.

technosophos on May 11, 2018

Please re-open, I’ve just encountered this on releases that have status ‘DEPLOYED’, on Helm 2.9.0:

Error: UPGRADE FAILED: cannot re-use a name that is still in use

REVISION	UPDATED                 	STATUS    	CHART           	DESCRIPTION                                                 
1       	Tue May  8 17:48:14 2018	SUPERSEDED	wordpress-0.1.10	Install complete                                            
2       	Tue May  8 18:16:30 2018	FAILED    	wordpress-0.1.10	Upgrade "planet4-flibble" failed: timed out waiting for t...
3       	Tue May  8 18:25:38 2018	SUPERSEDED	wordpress-0.1.10	Rollback to 1                                               
4       	Tue May  8 18:25:40 2018	SUPERSEDED	wordpress-0.1.10	Upgrade complete                                            
5       	Tue May  8 19:38:33 2018	SUPERSEDED	wordpress-0.1.10	Upgrade complete                                            
6       	Wed May  9 17:28:29 2018	FAILED    	wordpress-0.1.10	Upgrade "planet4-flibble" failed: timed out waiting for t...
7       	Wed May  9 18:44:37 2018	SUPERSEDED	wordpress-0.1.10	Rollback to 5                                               
8       	Wed May  9 18:44:39 2018	SUPERSEDED	wordpress-0.1.10	Upgrade complete                                            
9       	Wed May  9 19:07:23 2018	DEPLOYED  	wordpress-0.1.10	Upgrade complete

Tiller:

[tiller] 2018/05/09 09:59:55 rendering wordpress chart using values
[storage] 2018/05/09 09:59:55 getting last revision of "planet4-flibble"
[storage] 2018/05/09 09:59:55 getting release history for "planet4-flibble"
[storage] 2018/05/09 09:59:55 getting release history for "planet4-flibble"
[tiller] 2018/05/09 09:59:55 failed update prepare step: cannot re-use a name that is still in use

27Bslash6 on May 9, 2018

FWIW, another workaround is to patch the last configmap, changing the label STATUS to DEPLOYED.

atombender on May 4, 2018