Change to use AZ name instead of zone index enable topology spread co…

[andrew-edgar]

Add use of topology spread constraints and change to use AZ name not index for multiple diego-cell cluster requirements.

Solves issues of having duplicate names of cells when having one cluster / AZ in our desired cluster topology.

Also allows a single stateful set to range over AZs using the topology spread contraints and does not require multi-az support to ensure spread across zones.
Check item if necessary.

• Review PRs of changed Quarks dependencies
• Update this PR after the release of Quarks dependencies

Related and must be deployed with PR cloudfoundry-incubator/quarks-operator#1328

[manno]

@andrew-edgar can you format the files properly so 'lint' passes?

[andrew-edgar]

Voila now at least the link passes. thanks

[manno]

I need to figure out how to enable tests for outside PRs

[jandubois]

I'm off this week, but just wanted to make sure y'all have considered the implication of the naming change to upgrades!

Traditionally we have always had problems with upgrades whenever we changed names for pods, jobs, services etc.

I have not looked at this PR at all, but want to make sure you test upgrade scenarios before merging.

[manno]

cloudfoundry-incubator/quarks-operator#1303 (comment)

The DNS corefile change might cause issues while updating, as old names (z0) are not resolvable anymore

This affects the quarks-operator as soon as we include a qsts version with the change.
My solution would be to mention it in the release notes and bump quarks-operator to 8.0-pre1 (or so).

KubeCF can just stay on the old version?

[jandubois]

KubeCF can just stay on the old version?

I don't understand what this achieves. Isn't the whole point of changing the naming scheme so that KubeCF will use it?

If there is no way to upgrade an existing setup to use the new Quarks operator, it also means that kubecf will be stuck on the current operator forever? Who would be using the modified version of the operator?