[charts/redis-ha] merge nameOverride into fullnameOverride

[jimethn]

What this PR does / why we need it:

Eliminate nameOverride setting and migrate its functionality to fullnameOverride.

The difference between nameOverride and fullnameOverride is not semantically clear, with the former adjusting the app labels while the latter adjusts the resource naming. In practice, this means that if you want to change either, you probably want to change both.

Which issue this PR fixes

• fixes #167

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• [x] DCO signed
• [x] Chart Version bumped
• [x] Variables are documented in the README.md
• [x] Title of the PR starts with chart name (e.g. [stable/mychartname])

[jimethn]

@DandyDeveloper can you please review?

[DandyDeveloper]

I'm hesitant with this change as the impact is pretty big to people using it. Also, there is justifiable reasons for both.

This sounds more like I should investigate why there is no clear syntactical difference between them.

[jimethn]

@mkilchhofer for a detailed description of the problem being solved, see the issue it closes: https://github.com/DandyDeveloper/charts/issues/167

[jimethn]

The chart works fine without this change as long as it's the only installation of the chart in the namespace. If you ever install a second redis in the same namespace, the two clusters will interfere with each other.

Probably most users only ever install a single redis cluster, which is why more people haven't hit this problem.

[mkilchhofer]

Ok. But it can't happen due to the selector. All selectors contains the .Release.Name.

So when you install the chart twice like this

• helm install redis1 dandydev/redis-ha
• helm install redis2 dandydev/redis-ha

Sectors should be fine?

[DandyDeveloper]

There's a separate PR that covers the "hijacking" issue a little bit better. I'm closing this in favor of that.