Compute AZs should not be used as Volume AZs

[stephenfin]

/kind feature

Describe the solution you'd like

In #1030, we added support for defining root volume AZs, closing #1021. When this was implemented, a decision was made to use the MachineSpec's failureDomain attribute to populate rootVolume.availabilityZone if the latter was not configured. This feels like an anti-pattern. Compute AZs are not Volume AZs, and while they may be identical in smaller, simpler deployments with a single AZ (Cinder's default AZ is nova to allow this) or hyper-converged deployments, where nova-compute and cinder-volume run side-by-side on hosts, it's unlikely to be the case elsewhere. I've seen this pop up already in different deployments.

Is there any reason why we can't default to no implicit AZ or at least validate the implicit AZ exists?

Anything else you would like to add:

I'm not sure if this change in behavior would need to be placed behind an API version or not. Would welcome input in any case.

[mdbooth]

Before #1030 we let Nova create the root volume for us. I'm pretty sure my intention at the time was to copy the behaviour of Nova to minimise the change involved, so I certainly believed that Nova would explicitly request a cinder volume in an AZ with the same name as the Nova AZ if a Nova AZ was given. I can't remember how deeply I checked that at the time, though.

However, there's no reason we can't change it now. I believe it would be a breaking API change, so if we think this is important to change let prioritise it so we get it in before v1beta1.

We could do something like this in the current version:

  rootVolume:
    size: 50
    ignoreMachineAZ: true

In the next version we could flip the default and add:

  rootVolume:
    size: 50
    useMachineAZ: true

[mdbooth]

I think we could be even simpler than this. On up-conversion, if the AZ was not previously given we hydrate it to... we can't do that because the AZ is in the Machine object not the OpenStackMachine object, so isn't available during conversion :( As you were.

[stephenfin]

Before #1030 we let Nova create the root volume for us. I'm pretty sure my intention at the time was to copy the behaviour of Nova to minimise the change involved, so I certainly believed that Nova would explicitly request a cinder volume in an AZ with the same name as the Nova AZ if a Nova AZ was given. I can't remember how deeply I checked that at the time, though.

I thought the same until I went and investigated. It turns out this is the behaviour of Nova but only if [cinder] cross_az_attach is set to False. I documented this (and various other bits of AZ-relatd info) in a blog post.

However, there's no reason we can't change it now. I believe it would be a breaking API change, so if we think this is important to change let prioritise it so we get it in before v1beta1.

We could do something like this in the current version:

  rootVolume:
    size: 50
    ignoreMachineAZ: true

In the next version we could flip the default and add:

  rootVolume:
    size: 50
    useMachineAZ: true

I think we could be even simpler than this. On up-conversion, if the AZ was not previously given we hydrate it to... we can't do that because the AZ is in the Machine object not the OpenStackMachine object, so isn't available during conversion :( As you were.

Sounds like we have a strategy going forward so. Hurrah!

[EmilienM]

/assign EmilienM

[EmilienM]

/unassign Emilien
I have other tasks I want to tackle first in CAPO, so I'll let someone looking at it.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale