[stable/graylog] Release installed with helm2 cannot be upgraded using helm3

[juliohm1978]

Describe the bug
I have a graylog release installed with helm2, and I need to migrade our deploy pipeline to helm3. I have followed the steps outlined in the official docs successfully.

https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

After the release is migrated to helm3, a helm upgrade produces the following error:

[2020-01-22 18:53:45] helm3 upgrade --install -f values-dev.yaml --version 1.3.6 --set environment=dev --namespace logging --set pod.tag=. graylog-deploy stable/graylog
Error: UPGRADE FAILED: cannot patch "graylog-deploy" with kind StatefulSet: StatefulSet.apps "graylog-deploy" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

Using the helm template command, I was able to test each Yaml object created by the helm chart and isolate the issue to the Graylog StatefulSet.

The following is a snippet the StatefulSet currently deployed with helm2:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  creationTimestamp: "2020-01-07T21:49:30Z"
  generation: 1
  labels:
    app.kubernetes.io/instance: graylog-deploy
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: graylog
    app.kubernetes.io/version: 3.1.2-1
    helm.sh/chart: graylog-1.3.6
  name: graylog-deploy
  namespace: logging
  resourceVersion: "59348101"
  selfLink: /apis/apps/v1/namespaces/logging/statefulsets/graylog-deploy
  uid: 9a18c752-44c6-4dd5-9d85-c1ebc619fa49
spec:
  podManagementPolicy: OrderedReady
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/instance: graylog-deploy
      app.kubernetes.io/managed-by: Tiller
      app.kubernetes.io/name: graylog
  serviceName: graylog-deploy
  template:
    metadata:
      creationTimestamp: null
      labels:
        app.kubernetes.io/instance: graylog-deploy
        app.kubernetes.io/managed-by: Tiller
        app.kubernetes.io/name: graylog
        app.kubernetes.io/version: 3.1.2-1
        helm.sh/chart: graylog-1.3.6

And here is a snippet of the new StatefulSet rendered by helm3:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: graylog-deploy
  namespace: logging
  labels:
    app.kubernetes.io/name: graylog
    helm.sh/chart: graylog-1.3.6
    app.kubernetes.io/managed-by: "Helm"
    app.kubernetes.io/instance: "graylog-deploy"
    app.kubernetes.io/version: "3.1.2-1"
spec:
  serviceName: graylog-deploy
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: graylog
      app.kubernetes.io/instance: "graylog-deploy"
      app.kubernetes.io/managed-by: "Helm"
  updateStrategy: 
    type: RollingUpdate
  template:
    metadata:
      labels:
        app.kubernetes.io/name: graylog
        helm.sh/chart: graylog-1.3.6
        app.kubernetes.io/managed-by: "Helm"
        app.kubernetes.io/instance: "graylog-deploy"
        app.kubernetes.io/version: "3.1.2-1"

The breaking point here is that the chart renders the labels using a different value for app.kubernetes.io/managed-by.

The Yaml deployed by helm2 reads app.kubernetes.io/managed-by: Tiller while the new Yaml created by helm3 reads app.kubernetes.io/managed-by: "Helm". Kubernetes consideres the field .spec.template.metadata.label immutable for StatefulSets.

The exact template line: https://github.com/helm/charts/blob/master/stable/graylog/templates/statefulset.yaml#L26

Suffice to say that the value for .Release.Service has changed from helm2 to helm3, and that is causing the chart to break upgrades under helm3.

Version of Helm and Kubernetes: Helm 3, Kubernetes 1.15.3

Which chart: 1.3.6

What you expected to happen:
I expect the chart to render all metadata compatible with previous releases. I'm not sure what the best option would be right now, aside from just fixating app.kubernetes.io/managed-by: Tiller to maintain backward compatibility.

How to reproduce it (as minimally and precisely as possible):

• Install the graylog chart using helm2.
• Migrate the installed release to helm3
• Upgrade the release using helm3

[juliohm1978]

I submitted a PR to fix the label with value Tiller, but I'm wondering if this can be done by redefining the label only if it's coming from values.yaml.

This allows future installations to continue using the default value from .Release.Service and give the chance to old installations to upgrade by keeping the value Tiller fixed.

EDIT: closed in favour of the next PR

[juliohm1978]

I hope PR #20464 makes more sense now. Instead of a hard coded value for the affected label, a flag in values.yaml can be used by people in this situation. If enabled, the chart preserves the label installed by helm2.