Server block device mapping

[dalehenries]

Summary

• Add boot-time block device mapping (BDM) to the Server resource, enabling
  boot-from-volume and custom disk configurations at server creation time
• Add ServerBlockDeviceSpec type supporting sourceType (volume/image/blank),
  with references to ORC Volume and Image objects
• Make imageRef optional on ServerResourceSpec to support boot-from-volume
  without a top-level image reference
• Add CEL validations enforcing sourceType/ref consistency and requiring either
  imageRef or a bootable block device
• Add bdmVolumeDependency and bdmImageDependency with deletion guards
• Add three KUTTL E2E test suites: boot-from-image BDM, boot-from-existing-volume
  BDM, and BDM dependency ordering/deletion guards

Details

Block device mapping is immutable after creation and complements the existing
mutable volumes field (post-creation hot-attach). The blockDevices field maps
directly to Nova's block_device_mapping_v2 via gophercloud's servers.BlockDevice.

API changes

• ServerResourceSpec.ImageRef changed from KubernetesNameRef to
  *KubernetesNameRef (now optional)
• New ServerResourceSpec.BlockDevices []ServerBlockDeviceSpec field (immutable)
• New ServerBlockDeviceSpec struct with fields: sourceType, volumeRef,
  imageRef, bootIndex, volumeSizeGiB, destinationType,
  deleteOnTermination, diskBus, deviceType, volumeType, tag
• CEL validation on ServerResourceSpec: requires either imageRef or a block
  device with bootIndex == 0

Test plan

• server-create-bdm: Boot from volume using image source (no top-level
  imageRef), verify ACTIVE with volume attached
• server-create-bdm-volume: Boot from existing ORC Volume, verify ACTIVE
  with volume attached
• server-bdm-dependency: Verify server waits for missing BDM image, becomes
  available when created, image has deletion guard finalizer
• Existing server-create-minimal and server-create-full tests continue
  to pass (imageRef still works)

[dalehenries]

Fixes issue #365

[eshulman2]

Hey @dalehenries! Thanks for working on this. I wanted to make sure you notice that we already have PR #634 addressing boot-from-volume. #634 should cover BFV but if you notice a feature missing in it feel free to propose a patch that overlays on it :)

While going through your implementation, I noticed some violations of ORC's core principles. I'd recommend checking the development docs to understand the project philosophy better.

For example, the implementation creates OpenStack resources inline rather than referencing ORC objects. This creates a Cinder volume directly in OpenStack instead of referencing an ORC Volume CR. This violates the core principle from our docs:

ORC dependencies can only be expressed between ORC objects. Therefore if one OpenStack resource depends on another, that relationship can only be expressed in ORC if both resources have corresponding ORC objects.

In ORC, volumes should be created as Volume CRs and then referenced, not created inline during Server creation.

Another example is exposing deleteOnTermination which can create orphaned resources - if set to false, Nova doesn't deletes the OpenStack volume and ORC leaves an orphaned volume on the openstack cluster which the user can't see from the ORC scope.

Would be very glad to see more contributions to the project in the future! Let me know if you have questions/I can help in any way.