Grafana: Prepare chart for 5.1.x

[sylr]

When upgrading to 5.1.x we need to chown the whole /var/lib/grafana dir in order to comply with the new grafana user id used in the latest docker image.

[sylr]

/assign unguiculus

[christian-roggia]

I would use command: ["chown", "-R", "472:472", "/var/lib/grafana"] here.

[sylr]

All right

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sylr
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: unguiculus

Assign the PR to them by writing /assign @unguiculus in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[unguiculus]

#5386 updated Grafana to 5.1.2. I think this PR is now obsolete.

[sylr]

It's not if you think about upgrading your helm installed grafana from anything below 5.1.0.

If the permissions are wrong grafana will crash.

It's why I did this.

[OndroNR]

I wanted to deploy grafana with clean persistent volume and encountered this issue. I made one-run Job, based on init container in this PR, to fix ownerhip. This PR is still needed.

[sylr]

Could we merge this ASAP for people like @OndroNR that are going to upgrade grafana and be stuck.

[OndroNR]

I was doing clean install with enabled persistence.

[unguiculus]

/ok-to-test

[unguiculus]

This is not ideal. If you use a custom image that has a different versioning scheme, this won't work. I think it would be best to make this optional with a flag.

[sylr]

I prefer to let it like this, if you want to use custom images you should tag them correctly.

[FrederikNJS]

As I mentioned in #5635, I also just ran into the permission problem with persistent volumes.

[scottrigby]

Hi everyone, after a Charts maintainers conversation, the root of the problem appears to be that semver was not properly followed in #5386 in a way that was non-obvious:

• The MINOR version was bumped (from 1.8.0 to 1.9.0) which made sense, because a new feature was added (RBAC)
• However, the image and app version was also bumped (from 5.0.4 to 5.1.2), which is the Grafana version that introduced backwards incompatible changes. Even though Grafana version did not follow semver here, the chart should.
  • Note that while our automated do semver comparison, AFAIK we don't explicitly mention semver as a requirement anywhere except in the Un-deprecating A Chart section of our PROCESSES doc

Given that we accidentally missed this in #5386, we should change this PR from attempting to automatically handle this change, to adding a note to the user that if upgrading from < 1.9.0, to run a k8s-specific command (kubectl exec ... -it chown -R 472:472 /var/lib/grafana), and link to the Grafana documentation page on this in the same note rather than in an automated template step.

Additionally this PR should address the earlier oversight by properly bumping the MAJOR version (to 2.0.0).

Let's use #5657 for tracking creating and documenting the charts-wide policy for handling cases like this. Practically, the question for this PR now is where to communicate the above info to upgrading users so that they're less likely to miss it? I'm thinking maybe a new Upgrading section just above Installing the chart?

[willejs]

Would setting the fsGroup in securitycontext of the pod fix this for new installs?

[thomasbarton]

currently stable/grafana is broken when doing a clean install with a persistent volume. This pr fixes the issue. Any update on merging?

[xmartinez]

@scottrigby Not sure the semver reasoning applies to this issue. This is broken for fresh installs, where backwards compatibility consideration do not apply (there is no previous install to be compatible with).

For the sake of anyone encountering this issue, the following workaround can be applied:

kubectl create --filename=- <<'EOF'
apiVersion: batch/v1
kind: Job
metadata: {name: grafana-chown}
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: grafana-chown
        command: [chown, -R, "472:472", /var/lib/grafana]
        image: busybox:latest
        volumeMounts:
        - {name: storage, mountPath: /var/lib/grafana}
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

Note that kubectl exec cannot be used, because the container is crash-looping on startup, so it does not live long enough to be able to run any command.

[monotek]

@sylr
could you resolve the merge conflicts please?

[sylr]

@monotek AFAIU This is not going to be merged.

[monotek]

ok, thanks for the info anyway :-)

[immunda]

This was a real pain to get to the bottom of and is still broken on fresh installs as outlined above.

I independently came up with the same initContainer solution as the only viable option after exploring fsGroup for the pod's security context.

Any chance of a revisit @scottrigby?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Activing will cause the issue to no longer be considered stale. Thank you for your contributions.