OSASINFRA-4031: Feature parity with CAPO: add additional fields to server controller #623
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
eshulman2
changed the title
github-actions
bot
added
semver:major
Add metadata field to server controller allowing setting metadata on servers created by orc
Add SchedulerHints to server controller NOTE! this change MOVED the ServerGroupRef inside the ServerSchedulerHints
Enables creating bootable volumes from images by adding an imageRef field to the Volume spec. When specified, the volume is created with the image baked in, making it suitable for boot-from-volume scenarios. Changes: - Add imageRef field to VolumeResourceSpec - Add bootable and imageID fields to VolumeResourceStatus - Add image dependency with deletion guard - Add kuttl tests for bootable volume creation assisted-by: claude
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
eshulman2
changed the title
mandre
reviewed
Jan 2, 2026
Collaborator
mandre
left a comment
mandre
left a comment
There was a problem hiding this comment.
Wow, there's quite a lot in there. Thanks for the PR!
Just a few notes before I start reviewing this PR more thoroughly:
- in the future, let's have individual PR if possible to make it easier to review and merge, similar to how @winiciusallan did in #616.
- this is an upstream project that manages its issues in github, we shouldn't add jira references to the PR title.
- avoid breaking backward compatibility unless it's absolutely required
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.
This PR implements server controller feature parity with CAPO (Cluster API Provider OpenStack), enabling the eventual migration from CAPO's internal OpenStackServer controller to ORC.
Closes #624
Contributes to #577
Related: kubernetes-sigs/cluster-api-provider-openstack#2814
Changes
Server Controller Enhancements
Metadata support
ConfigDrive support
SchedulerHints support
Boot-from-Volume support
Volume Controller Enhancements
ImageRef support
Design Decisions
Boot volume vs data volumes separation
No deleteOnTermination option
assisted-by: claude