Output of helm version:

$ helm version
Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.15.2", GitCommit:"8dce272473e5f2a7bf58ce79bb5c3691db54c96b", GitTreeState:"dirty"}

Output of kubectl version:

$ ./kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

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

Over the past few months there have been numerous issues opened for this very issue[1] and in the end they were mostly closed as "working as designed" / "this is a k8s problem". When looking at the k8s issues linked, k8s also seems to be "working as designed".

[1]#6583
#6969

I've been digging through the helm code the past couple days to better understand the problem / try to hack a solution together. My understanding of the problem is (simplified):

1. Install k8s 1.15
2. helm install a chart w/ deployment @ apps/v1beta1

• helm stores these templates in a config map for later operations

3. upgrade k8s to 1.16

• k8s automagically "upgrades" the deployment to apps/v1

4. Update chart to use apps/v1
5. helm upgrade

The helm upgrade fails as it attempts to create a diff patch from steps 2 to 4. The problem is that helm doesn't know that it's source is no longer valid for the current version of k8s.

There have been a number of solutions proposed, but I wonder if there is a k8s API that helm could call to "upgrade" the API in the same manner that happens when moving from 1.15 -> 1.16? Perhaps there is a way to do that when calling BuildUnstructured ? I'm game for any and all suggestions.

Another thought... Perhaps have a new helm flag that would force update based off the current template values (put rather than patch). This assume that the new template has a 'valid' api version specified.

A few other comments:

• Right now I'm talking about deployments, but I'm fairly certain this is a common problem across any number of other apis.
• Destructive operations are a no-go due to use of statefulsets.
• This might be a crappy, but workable workaround[1] ?

[1] #6969 (comment)