New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
helm upgrade --install no longer works #3208
Comments
I thought I was experiencing the same problem, but it turned out I just had an old delete (but not purged), release hanging around. check helm list -a , and if your release is there, helm delete --purge releasename. |
This is a side-effect of fixing issues around upgrading releases that were in a bad state. #3097 was the PR that fixed this issue. Is there an edge case here that we failed to catch? Check |
Also having the same problem, along with duplicate release names:
|
When you were upgrading, what message was displayed? |
same error as the diff above, but an install would say it was already installed. |
I mean in the previous upgrade attempts that ended up in a FAILED status. I want to know how we get into the situation where all releases are in a failed state. |
Ohh, the duplicate release name deployments? That I'm not sure, I get it quite often. Sometimes they are all in a DEPLOYED state, sometimes a mix of FAILED and DEPLOYED. We use a CI/CD Jenkins server that constantly updates every PR merge so we do several |
I seem to have ended up with something similar, I see a few duplicates in my releases lists:
All of them seem to be in a DEPLOYED state, but it could well be that a previous upgrade failed at some point, as I have hit that bug several times. I am still on K8S 1.7, so have not updated to helm 2.7 yet. |
Same issue, can't upgrade over FAILED deploy |
Same here using 2.7.2. The first attempt of a release was failed. Then when I tried an upgrade --install I've got the error "Error: UPGRADE FAILED: "${RELEASE}" has no deployed releases". |
Same problem here with 2.7.2,
|
If the release is entirely purged with |
I'm experiencing the same problem. Combined with #3134 that leaves no option for automated idempotent deployments without some scripting to workaround. @winjer just tried deleting with --purge and for me it didn't work although the error changed |
@prein This is because you have a service that is not "owner" by helm, but already exists in the cluster. The behaviour you are experiencing seems correct to me. The deploy cannot succeed because helm would have to "take ownership" of an API object that it did not own before. It does make sense to be able to upgrade a FAILED release, if the new manifest is actually correct and doesn't content with any other resources in the cluster. |
I'm also seeing this behavior on a release called
I will have to delete this to be able to continue to deploy, let me know if there is anything I can do to help debug this. |
I actually have another duplicate release on my cluster, if you have any command for me to run to help debug that? Let me know! |
just upgraded to tiller 2.7.2 and we're seeing the same thing. |
Looks like you can restore the release by rolling back to the deleted version. |
`helm list` should only list latest release fixes helm#3208
`helm list` should only list latest release fixes #3208
seeing the same issue with |
Also seeing two potential versions of this issue:in CI:
on my local machine:( both at my OSX bash and in a gcloud/kubectl container )
The warnings are normal for our chart.
|
@adamreese what is the final resolution for this issue? We're on 2.8 and we still cannot upgrade a previously In particular, we're running into the following type of issues:
Deleting/purging is not desirable or acceptable here: the release may have multiple resources (pods, load balancers) that are not affected by the one resource that won't go up. In previous Helm versions, Helm is the owner of all resources involved at all times here -- the resource is only marked |
Thanks -- that clears it up. Actually realized we were only hitting it when we had no successful release to begin with. In that case, purge is a fine workaround. |
@MythicManiac FWIW: |
We also have this problem. It's very annoying that I need to delete K8s services and related AWS ELBs because helm |
As a very hacky workaround, if the problem with the origin deploy is
resolvable (e.g. preexisting service.), Doing a rollback to the original
failed release can work.
…On Fri, 5 Oct 2018, 18:13 Eugene Glotov, ***@***.***> wrote:
We also have this problem. It's very annoying that I need to delete K8s
services and related AWS ELBs because helm has no deployed releases. The
package manager is great but this issue leads to production downtime which
is not good.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3208 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz>
.
|
@tcolgate, thank you! I just fixed another problem (#2426 (comment)) with your workaround and will try to test it for exist ELBs when I am deploying a new chart next week over existing resources. |
@tcolgate, I just tested and no, it doesn't work in the case of first deploy.
|
I am curious, if Helm can't deploy a chart over existing resources so why |
@thomastaylor312, we faced this issue |
I found this thread after a I decided to see if it was an issue because of an incorrect --set value, and --debug --dry-run --force actually STILL deleted my running pod ... my expectation was that a dry run action would NEVER modify cluster resources. It did work though, and the service could be redeployed afterwards, but we experienced downtime. |
This is a fair expectation -- we should make that... not happen |
I believe that was patched in #4402 but it'd be nice if someone were to check. Sorry about that! |
same problem after upgrade to 2.11.0 |
Cross post: |
Why is this closed? Do we have a proper way to handle this now? |
@gerbsen, there isn't a way around this with current versions of Helm that is non-destructive. |
Just had |
@notque after losing all grafana dashboard twice I've started doing backups before doing any kind of upgrade, having this kind of risk removes all the benefits of using helm |
For those who are seeking for help, the issue was gone for me after upgrading helm to v.2.15.2 |
Still seeing this issue on |
Why is it still closed? 2.16.1 is still affected |
@nick4fake I think it's a duplicate of #5595 |
As of helm v2.7.1, after updating tiller, running helm upgrade --install flag no longer works. The following error is displayed: Error: UPGRADE FAILED: "${RELEASE}" has no deployed releases. Downgrading to v2.7.0 or v2.6.2 does not produce the error.
The text was updated successfully, but these errors were encountered: