[stable/redis] Add chart and release labels in pods

[javsalgar]

What this PR does / why we need it:

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #

Special notes for your reviewer:

[carrodher]

/ok-to-test
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: carrodher, javsalgar

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:

• stable/redis/OWNERS [carrodher]

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

[desaintmartin]

Hello guys,
Doesn't all of these PRs break k8s/helm upgrades (helm/helm#2494) ?

[paultiplady]

Confirmed, these changes appear to have broken backwards-compatibility with existing deployments, and should therefore require a major version bump, rather than including in a point release.

[desaintmartin]

What I mean is that with those changes, EVERY version (even patch version) upgrade will break, not only this one.

[paultiplady]

Is the problem you're raising that there is no satisfactory migration path (even if it requires modifying the deployment outside of helm)?

[desaintmartin]

Well, the (temporary) satisfactory path is to revert those changes so that there is no mutable labels and we can actually use those Charts in production.
There should be a consensus about this problem for all charts of this repository, clear understanding of the problem (helm vs k8s and its implications) and it should be written on the guidelines of this repo.

[paultiplady]

That seems correct to me. Helm requires its charts use SemVer, under which It's a bug to break upgrades on a patch release.

As long as there's a documented upgrade procedure for a back-incompatible change on major release that would comply with the requirements of SemVer, though depending on how painful that migration is you could also deem it unacceptable, or hide it behind a feature-flag so that existing users don't need to take the upgrade.

[desaintmartin]

Well, I think it is not a matter of semver.
Let's break down the problem.
1/ This patch is applied. It breaks upgrades. Whatever fix is taken in order to make it upgradable (even if the "fix" is "upgrading major release to mark it incompatible")
2/ Everybody is happy
3/ A minor patch change is made to this chart. Something very tiny like "fix typo in readme". It will again break upgrade of an existing Release of this Chart, because spec.template.metatdata.labels now contains a "chart" entry which itself contains the version. spec.template.metatdata.labels being immutable for some k8s reason (in fact, the selector.matchLabels generated from this is immutable), k8s is not happy and prevents any upgrade.

This is causing a few confusions, like here:
#7441
Where the root of the problem is not understood.

This is at least my understanding, but I'm actually happy if I'm wrong (because this problem is blocking for me).

You are talking about point 1, which does not contain the whole story.

[paultiplady]

Thanks for the clarification, my understanding of the issue was incomplete. You're right, it sounds like this change simply isn't compatible with the way that k8s metadata is managed.

Providing a concrete link from the API docs, https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#selector.