Upgrade --install fails if previously uninstalled with --keep-history

[n3ziniuka5]

Output of helm version:

version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"dirty", GoVersion:"go1.15.6"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T21:51:49Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.14-gke.400", GitCommit:"b00b302d1576bfe28ae50661585cc516fda2227e", GitTreeState:"clean", BuildDate:"2020-11-19T09:22:49Z", GoVersion:"go1.13.15b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

GKE

This may be closely related to #5595, but I see that one is already closed.

Reproduction steps:

• Remove a release using helm uninstall --keep-history app
• Install it again using helm upgrade --install app app

helm upgrade fails with "app has no deployed releases".

This workflow is used when app is a distributed application. helm uninstall is called conditionlly when changes are not backwards compatible and a rolling release cannot be done. Otherwise we just call helm upgrade without helm uninstall

[bacongobbler]

I believe this is because to install over a release that has been previously uninstalled, you need to provide the --replace flag to helm install.

From helm help install:

--replace                      re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production

[n3ziniuka5]

But helm upgrade does not have a --replace flag. And as I said helm uninstall is done conditionally, so in one situation we may upgrade a release while in other it is a new install, just with preserved history.

Of course we could have separate logical branches in deployment scripts and make sure that we use either upgrade or install, but feels like upgrade --install is supposed to be used for exactly this purpose, right?

[bacongobbler]

I feel like this is a case where it goes against the norm. As the help text suggests, --replace is an unsafe feature flag, so we've opted out of automatically invoking this flag in cases where the user does not intentionally call it. Automatically implying unsafe feature flags in a production-safe workflow (helm upgrade --install) could lead to dangerous side effects for those unaware by --replace's behaviour.

I would be opposed to automatically adding unsafe flags under the user's nose. In these scenarios it's probably best for the user to intervene and use the --replace flag on an as-needed basis (i.e. they know what they're doing).

[n3ziniuka5]

Can you give a bit more context? helm upgrade --install is supposed to either upgrade a release, or install a new one if a release is not installed, right? In this case it does not do anything, so why is this not a bug?

[bacongobbler]

In the case where an "upgrade or install" is used in a typical scenario, absolutely. In this case however, to perform an install would be dangerous and could lead to unintentional behaviour. It is unclear whether the user invoking helm upgrade --install intends to replace the existing release ledger (helm install --replace) or purge the history and start fresh (helm uninstall && helm install). So we error out and ask the user to intervene.

This is also why helm upgrade does not always perform an upgrade in certain scenarios. For example, there can be cases where the previous release is now in a FAILED state, and the user has to manually intervene in order to proceed, either via helm rollback, helm upgrade --reset-values, or some other flag not automatically invoked.

Hope that helps.

[bacongobbler]

Closing this as intentional behaviour. Your call-to-action is to either invoke helm install --replace or remove the entire release ledger. Helm cannot determine which path is the correct course of action, so it exits. But you have to manually intervene here to resolve the conflict.

After moving forward with either of those paths, you can call helm upgrade --install as normal.

[n3ziniuka5]

Ok, thanks.

[gw0]

It is unclear whether the user invoking helm upgrade --install intends to replace the existing release ledger (helm install --replace) or purge the history and start fresh (helm uninstall && helm install).

I would say it is pretty clear, that with upgrade --install a user wants to get his app installed (no matter what) and because he previously used --keep-history he wants to continue with the existing release ledger/history.

"Solving" Helm3 issues by saying "it is intentional behaviour" is bad. Maybe it is time for Helm4 to fix its logic?

[TomasTokaMrazek]

Automatically implying unsafe feature flags in a production-safe workflow (helm upgrade --install) could lead to dangerous side effects for those unaware by --replace's behaviour.

Eh, and what is the actual behaviour then? The documentation on this flag is rather short and I personally do not see how it is dangerous. I am now quite hesitant to add this, since the documentation says it should not be used in production. But on the other hand I think, that keeping history of deployments should on the contrary be a production best practice.

I added --keep-history flag to preserve ledger of deployments, nothing more, nothing less, just to discover by several failed builds, that install fails with reused name, while upgrade fails with no deployments and after few searches away added the --replace flag. If keep history and replace are dependent, it should be noted in documentation.