Add boot-from-volume support to server controller #634
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
mandre
reviewed
Jan 21, 2026
| // +optional | ||
| // +kubebuilder:validation:XValidation:rule="self == oldSelf",message="imageRef is immutable" | ||
| ImageRef KubernetesNameRef `json:"imageRef,omitempty"` | ||
| ImageRef *KubernetesNameRef `json:"imageRef,omitempty"` |
Collaborator
There was a problem hiding this comment.
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.
mandre
approved these changes
Jan 21, 2026
| resource: | ||
| # No imageRef - booting from volume | ||
| bootVolume: | ||
| volumeRef: boot-volume |
Collaborator
There was a problem hiding this comment.
I believe we're missing a few refs in examples/components/kustomizeconfig/kustomizeconfig.yaml, we should fix it.
Contributor
Author
There was a problem hiding this comment.
@mandre should I add them in this patch or should we have a dedicated PR for that as it seems many references are missing?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Boot volume vs data volumes separation:
time via Nova's block device mapping
mechanism (spec.resource.volumes) which attaches volumes after server
creation
server creation) while the boot volume is immutable
runtime mechanisms
No deleteOnTermination option:
server is deleted, but the ORC Volume resource would remain as an orphan
leading to unexpected behavior
resources, maintaining consistent ORC resource lifecycle management
API Changes:
Controller Changes:
Tests & Examples:
depends on #633
assisted-by: claude