--force flag on helm upgrade doesn't replace resources

[jgazeau]

Output of helm version:

version.BuildInfo{Version:"v3.5.2", GitCommit:"167aac70832d3a384f65f9745335e9fb40169dc2", GitTreeState:"dirty", GoVersion:"go1.15.7"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.12-eks-7684af", GitCommit:"7684af4ac41370dd109ac13817023cb8063e3d45", GitTreeState:"clean", BuildDate:"2020-10-20T22:57:40Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Hi,

We are having an issue using the helm upgrade --install --force command on existing resources already installed in a bundle:

Error: rendered manifests contain a resource that already exists. Unable to continue with install: Service "service-sample-mongo-v1" in namespace "core-1" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "testjga": current value is "training-apps-test"

Here is our workflow:

1. Install a bundle containing several dependencies to other charts using the helm upgrade --install command
2. A new version of our dependency is released and we would like to deploy it without upgrading the whole bundle:
   1. Using Helm v2 the --force flag was working
   2. Using helm v3 we are getting the above error

Do you know if there was a regression on this command ?
Regards,

Jordan.

[jgazeau]

Don't know if it can help but it seems that a new check has been made on resources (induce by this commit and also this commit introducing more checks).
It seems that in every case this check is made without taking into account the --force flag ?

[bacongobbler]

In Helm 3, --force was changed to better match kubectl apply --force. The force flag no longer forces a delete and create in the case of a failure which was prone to many failure cases (timeouts, etcd leader loss, inconsistent state transitions...). Instead it tells Helm to issue a PUT request instead of a PATCH request.

See #7431 and #7082.

[bacongobbler]

In any case, what you are asking is to deploy a release with one Helm chart, then manage that same resource with another. You run into many issues managing the state of one resource with more than one chart. For that reason there is an explicit ownership check in Helm that prevents this case from occurring. So even if you were to fix the first issue, you'd likely run into others with your case.

I would suggest not attempting to manage one resource with multiple Helm charts. Each chart should be self-contained and should not rely on managing another chart's resources.

[jgazeau]

@bacongobbler , thanks for your help and your explanation. Seems pretty clear why it was implemented this way.