feat(server-clone): align boot-mode policy with server create - #4
Merged
Conversation
`orca server clone` kept emitting an unconditional block_device_mapping_v2 while `orca server create` had already switched to boot-from-image by default. Clone therefore silently recreated BFV servers even when the source's flavor carried a local root disk — defeating the whole point of the PR #3 migration. Wire the same --boot-from-image / --boot-from-volume flags on clone, reuse _resolve_boot_mode, and branch the Nova body the same way: * use_bfv=True → block_device_mapping_v2 (unchanged, honours --disk-size) * use_bfv=False → imageRef, Nova sizes the root disk from the flavor Error messages and mutual exclusion are identical to the create path.
Vinetos
pushed a commit
to Vinetos/orca-cli
that referenced
this pull request
May 30, 2026
Addresses the remaining high/medium findings from the 2026-04-20 audit: - stackopshq#4 insecure TLS warning + cacert path validation - stackopshq#7 atomic token cache writes - stackopshq#9 publish action pinned to immutable SHA - #13 CI gaps: Poetry cache, poetry build, gitleaks, pip-audit, deploy-docs gated on CI success
Vinetos
pushed a commit
to Vinetos/orca-cli
that referenced
this pull request
May 30, 2026
Documents the non-obvious default shift introduced by PR stackopshq#3 and PR stackopshq#4: `orca server create` and `orca server clone` now boot from image on the compute's local disk by default, falling back to boot-from-volume only when the flavor has `disk == 0`. Records the alternatives considered (unconditional ephemeral, the `--ephemeral / --boot-from-volume` pairing that was tried first) so a future contributor reading the diff does not silently undo the choice.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Context
PR #3 switched `orca server create` to boot-from-image by default, but `orca server clone` was left unchanged — it kept emitting an unconditional `block_device_mapping_v2`, which silently recreated BFV servers even when the source's flavor had a local root disk. Clone therefore worked against the grain of the new default.
Changes
Tests
New `tests/test_server_clone_boot_mode.py` (6 tests): auto-detect with `disk>0` and `disk=0`, both explicit flags, error on `--boot-from-image` + disk=0, mutual exclusion.
Backwards compatibility
Same posture as PR #3: the default changes, pipelines relying on the old BFV clone must pass `--boot-from-volume`.