Skip to content

Conversation

@eshulman2
Copy link
Contributor

Add support for booting servers from Cinder volumes instead of images.
This enables the boot-from-volume (BFV) pattern where a bootable volume
(created from an image) is used as the root disk.

Design decisions:

  1. Boot volume vs data volumes separation:

    • Only the boot volume (bootVolume field) is attached at server creation
      time via Nova's block device mapping
    • Additional data volumes continue to use the existing dynamic attachment
      mechanism (spec.resource.volumes) which attaches volumes after server
      creation
    • This separation allows data volumes to remain mutable (add/remove after
      server creation) while the boot volume is immutable
    • Avoids duplicating volume attachment logic between creation-time and
      runtime mechanisms
  2. No deleteOnTermination option:

    • Deliberately not exposing Nova's delete_on_termination flag
    • If enabled, Nova would delete the underlying OpenStack volume when the
      server is deleted, but the ORC Volume resource would remain as an orphan
    • The orphaned Volume resource would then attempt to recreate the volume,
      leading to unexpected behavior
    • Users who want the volume deleted should delete both Server and Volume
      resources, maintaining consistent ORC resource lifecycle management

API Changes:

  • Add ServerBootVolumeSpec type with volumeRef and optional tag fields
  • Add bootVolume field to ServerResourceSpec (mutually exclusive with imageRef)
  • Make imageRef optional (pointer) with CEL validation

Controller Changes:

  • Add bootVolumeDependency with deletion guard and unique controller name
  • Handle boot-from-volume in CreateResource by building BlockDevice list

Tests & Examples:

  • Add kuttl test for server boot-from-volume scenario
  • Add config/samples/openstack_v1alpha1_server_boot_from_volume.yaml
  • Add examples/bases/boot-from-volume/ with volume and server examples

depends on #633

assisted-by: claude

@github-actions github-actions bot added the semver:major Breaking change label Jan 8, 2026
Add support for booting servers from Cinder volumes instead of images.
This enables the boot-from-volume (BFV) pattern where a bootable volume
(created from an image) is used as the root disk.

Design decisions:

1. Boot volume vs data volumes separation:
    - Only the boot volume (bootVolume field) is attached at server creation
    time via Nova's block device mapping
    - Additional data volumes continue to use the existing dynamic attachment
    mechanism (spec.resource.volumes) which attaches volumes after server
    creation
    - This separation allows data volumes to remain mutable (add/remove after
    server creation) while the boot volume is immutable
    - Avoids duplicating volume attachment logic between creation-time and
    runtime mechanisms

2. No deleteOnTermination option:
    - Deliberately not exposing Nova's delete_on_termination flag
    - If enabled, Nova would delete the underlying OpenStack volume when the
    server is deleted, but the ORC Volume resource would remain as an orphan
    - The orphaned Volume resource would then attempt to recreate the volume,
    leading to unexpected behavior
    - Users who want the volume deleted should delete both Server and Volume
    resources, maintaining consistent ORC resource lifecycle management

API Changes:
- Add ServerBootVolumeSpec type with volumeRef and optional tag fields
- Add bootVolume field to ServerResourceSpec (mutually exclusive with imageRef)
- Make imageRef optional (pointer) with CEL validation

Controller Changes:
- Add bootVolumeDependency with deletion guard and unique controller name
- Handle boot-from-volume in CreateResource by building BlockDevice list

Tests & Examples:
- Add kuttl test for server boot-from-volume scenario
- Add config/samples/openstack_v1alpha1_server_boot_from_volume.yaml
- Add examples/bases/boot-from-volume/ with volume and server examples

assisted-by: claude
// +optional
// +kubebuilder:validation:XValidation:rule="self == oldSelf",message="imageRef is immutable"
ImageRef KubernetesNameRef `json:"imageRef,omitempty"`
ImageRef *KubernetesNameRef `json:"imageRef,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of this change, we'll have to cut a new major release since it's not backward compatible. This settles the discussion in #632.

resource:
# No imageRef - booting from volume
bootVolume:
volumeRef: boot-volume
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we're missing a few refs in examples/components/kustomizeconfig/kustomizeconfig.yaml, we should fix it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mandre should I add them in this patch or should we have a dedicated PR for that as it seems many references are missing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preferably in a different patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

semver:major Breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants