Helm 3 upgrade failed - Immutable field.

[Dimpison]

When any of immutable fields was changed in template, helm upgrade fails because it can't update resources (output below).

Steps to reproduce:
helm create chart
helm upgrade --install nginx ./chart --wait --timeout 300s --atomic --cleanup-on-fail --force

Release "nginx" does not exist. Installing it now.
NAME: nginx
LAST DEPLOYED: Fri Dec  6 13:07:52 2019
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=chart,app.kubernetes.io/instance=nginx" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:80

vim chart/templates/_helpers.tpl (and add a couple of symbols into line number 50, in order to change label selector)

appq.kubernetes.io/name: {{ include "chart.name" . }}

helm upgrade --install nginx ./chart --wait --timeout 300s --atomic --cleanup-on-fail --force

client.go:399: Replaced "nginx-chart" with kind ServiceAccount for kind ServiceAccount
Error: UPGRADE FAILED: failed to replace object: Service "nginx-chart" is invalid: spec.clusterIP: Invalid value: "": field is immutable && failed to replace object: Deployment.apps "nginx-chart" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/instance":"nginx", "appq.kubernetes.io/name":"chart"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Output of helm version:

$ helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

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

[bacongobbler]

Kubernetes marks certain fields of objects as immutable. Once the object has been created, those fields cannot be changed. This is something out of Helm's control as per the normal patch operations.

In your particular case, #6378 (comment) contains an in-depth write-up on the behaviour. I guess that same practice should be applied to the default starter chart. If you'd like to implement that for the starter chart, please feel free!

There is some discussion in #7082 about deleting and re-creating objects on an upgrade. It's not ideal as it can cause downtime, however it's an additional option that can work around this behaviour in certain scenarios.

[bacongobbler]

Helm upgrade is similar to kubectl apply’s behaviour. You can use the -force flag to bypass the three-way merge patch strategy. That would be the equivalent of a kubectl replace.

[mssachan]

@bacongobbler We are deploying StorageClasses as part of our chart and StorageClass's parameters are immutable. So in next release, when we update value of some StorageClass parameter, then also helm upgrade --force is failing.
Not sure how to handle this case for StorageClasses updation. Any suggestions?

Error: UPGRADE FAILED: failed to replace object: StorageClass.storage.k8s.io "ibmc-s3fs-standard-cross-region" is invalid: parameters: Forbidden: updates to parameters are forbidden.

It was working fine in helm v2 as helm upgrade --force used to force delete and recreate StorageClass.

[sc250024]

I'm seeing the same thing for Service, Deployment, ServiceMonitor objects as well. I'm using the --force flag in all of those cases.

[jamesrcounts]

Simply removing the --force flag resolved this for me.

[cdunford]

Is there any sort of sure-fire workaround for this issue for the time-being? I see it occasionally, and am left trying to clean things up manually.