test(vmop): add e2e tests for VMOP superseding#2559
Merged
Conversation
1aec9bf to
14666b4
Compare
Add two deterministic e2e scenarios that verify a non-terminal VMOP transitions to the Superseded phase when a newer conflicting VMOP arrives for the same VM: - Start superseded by Stop: the VM is pinned to a non-existent node, so its launcher pod stays Unschedulable and the Start VMOP never leaves InProgress. - Migrate superseded by Stop: the migration target is pinned to a non-existent node, so the target pod stays Unschedulable and the Migrate VMOP stays in Scheduling/InProgress. Pinning the workload to a non-existent node keeps the superseded operation in a non-terminal phase without any timing race. Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
Extend the VMOP superseding e2e suite beyond Start->Stop: - Migrate superseded by Stop or Restart: parametrized over the superseding operation; the migration target is pinned to a non-existent node so the Migrate VMOP stays InProgress. - Restart superseded by a forced Stop or Restart: the VM CPU cores are bumped beyond cluster capacity, which is a restart-required change (socket topology changes) rather than a hotplug migration, so the restarted launcher pod stays Unschedulable and the Restart VMOP stays InProgress. All scenarios keep the superseded operation in a non-terminal phase without a timing race and assert it reaches the Superseded phase. Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
b35fa13 to
0001f11
Compare
Isteb4k
approved these changes
Jun 30, 2026
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
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.
Description
Adds e2e coverage for the
SupersededVMOP phase introduced in #2492.Two deterministic scenarios verify that a non-terminal VMOP transitions to the
Supersededphase (with conditionCompleted, reasonSuperseded) when a newerconflicting VMOP arrives for the same VM:
launcher pod stays
Unschedulableand theStartVMOP never leavesInProgress.node, so the target pod stays
Unschedulableand theMigrateVMOP stays inScheduling/InProgress.Both tests run under
Label(precheck.NoPrecheck).Why do we need it, and what problem does it solve?
The
Supersededphase (#2492) shipped without e2e coverage. The hard part oftesting superseding is timing: the operation being superseded must still be
non-terminal when the superseding VMOP arrives. A fast workload (e.g. an Alpine
VM that migrates in seconds) makes such a test inherently racy.
Pinning the workload to a non-existent node removes the race entirely: the
launcher / migration target pod is permanently
Unschedulable, so thesuperseded operation stays in a non-terminal phase for as long as needed,
without
sleeps or stress generators.What is the expected result?
Both specs pass:
Checklist
Changelog entries