[scs2] Diskless flavors in multi-AZ clouds failure

[garloff]

/kind bug

What steps did you take and what happened:
I created a multi-worker cluster where I used worker nodes with diskless flavors (e.g. workerFlavor=SCS-2V-4) and thus a non-zero volume size for the worker (workerRootDisk=50).
This ended up with one worker node failing:

│ fault                                ┆ {"code":500,"created":"2026-04-24T12:54:49Z","details":null,"message":"Build of instance      │
│                                      ┆ a53e579b-b653-44e4-ad0e-973c118a61e3 aborted: Invalid volume: Instance                        │
│                                      ┆ a53e579b-b653-44e4-ad0e-973c118a61e3 and volume 24769d3f-c4e7-4c24-b033-a0563fe4768a are not  │
│                                      ┆ in the same availability_zone. Instance is in nbg6. Volume is in nbg1"}                       │
│ status                               ┆ ERROR                                                                                         │

The error message is clear. When I create a VM with a diskless flavor, someone (capo in this case) needs to create a bootable volume from the image and then boot from it. In many clouds, cross-az volume attachment is disallowed. (In those clouds where it is allowed, it's still a bad idea for performance reasons -- except if your storage is global, of course.)

No explicit availability zone (failure domain) was passed to capo, so we left it to the system to determine this ... without luck.

What did you expect to happen:
openstack server create --block-device boot_index=0,source_type=image,uuid=$IMGID,destination_type=volume,volume_size=50,delete_on_termination=true ... always works, because the nova scheduler picks a host first and then passes the availability zone from that host to cinder for volume creation and insists on it iif cross-attachment is not enabled. (This works only if storage and compute AZs have a 1:1 mapping with identical names, which is the case on sane clouds.)
I expected capo to take care of this.

Anything else you would like to add:
I could work around using diskful flavors.
Or I could explicitly force an availability zone on my workers (machine deployement), yet I have to work this into the automation to be able to pass it down.

However, I would expect for capo to be more clever here and do as nova does: get a AZ from the nova scheduler and then pass it to conder for the volume creation.

Environment:

• noris Sovereign Cloud (three AZs for compute and for volumes)
• ClusterStack openstack-scs2-1-34-v0-git-8271ca4 with kubernetes-v1.34.7
• scs-training-kaas-scripts for management

[garloff]

Looks like in our openstackMachineTemplate, we need to default to
rootVolume.availabilityZone.from: Machine
so we inherit the "failureDomain" from the VM.

[garloff]

Above mentioned should work if we set failureDomain in the cluster's topology for the machinedeployment.
(spec.topology.workers.machineDeployments)
Whether it still works when we do not set it, I don't know.
(Update: It does not.)

We may not be able to hardcode this in the openStackMachineTemplate, as there are two possible cases:

• Some clouds have one global storage AZ (while implicitly distributing the storage over all AZs)
• Some clouds have one storage AZ per compute AZ
• Even more fancy setups are possible, though I would not consider them sane enough to require supporting them out-of-the-box.

[garloff]

So here's a confirmed working state on nSC (3AZ with local storage AZs):
clusterclass:

spec:
  patches:
  - definitions:
    - jsonPatches:
      - op: add
        path: /spec/template/spec/rootVolume
        valueFrom:
          template: |
            sizeGiB: {{ .controlPlaneRootDisk }}
            availabilityZone:
              from: Machine
      selector:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: OpenStackMachineTemplate
        matchResources:
          controlPlane: true
    description: Sets the root disk size in GiB for control-plane nodes.
    enabledIf: '{{ if .controlPlaneRootDisk }}true{{end}}'
    name: controlPlaneRootDisk
  - definitions:
    - jsonPatches:
      - op: add
        path: /spec/template/spec/rootVolume
        valueFrom:
          template: |
            sizeGiB: {{ .workerRootDisk }}
            availabilityZone:
              from: Machine
      selector:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: OpenStackMachineTemplate
        matchResources:
          machineDeploymentClass:
            names:
            - default-worker
    description: Sets the root disk size in GiB for worker nodes.
    enabledIf: '{{ if .workerRootDisk }}true{{end}}'
    name: workerRootDisk

Resulting in openstackmachines

spec:
  flavor: SCS-8V-32
  image:
    filter:
      name: ubuntu-capi-image-v1.34.7
  providerID: openstack:///1e9be3de-0fb6-4f4a-8422-952737880576
  rootVolume:
    availabilityZone:
      from: Machine
    sizeGiB: 100

and now I can create a cluster with

spec:
  topology:
    workers:                     
      machineDeployments:                                           
      - class: default-worker                                       
        failureDomain: nbg1                                         
        name: md-1                                                  
        replicas: 1                                                 
      - class: default-worker 
        failureDomain: nbg3     
        name: md-3                                                  
        replicas: 1                                                 
      - class: default-worker                                       
        failureDomain: nbg6                                         
        name: md-6       
        replicas: 1                                                 

which will reliably come up.

[garloff]

Test release: openstack-scs2-1-34-v0-git-f4ddbaf