feat(vmop): add superseded phase#2492
Merged
Merged
Conversation
a62ae41 to
29ceb47
Compare
432ee94 to
f62e652
Compare
Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
005e659 to
3646946
Compare
Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
yaroslavborbat
approved these changes
Jun 30, 2026
prismagod
approved these changes
Jun 30, 2026
yaroslavborbat
approved these changes
Jun 30, 2026
4 tasks
danilrwx
added a commit
that referenced
this pull request
Jun 30, 2026
Adds e2e coverage for the Superseded VMOP phase introduced in #2492. Two deterministic scenarios verify that a non-terminal VMOP transitions to the Superseded phase (with condition Completed, reason Superseded) 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. Both tests run under Label(precheck.NoPrecheck). --------- Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
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
Add a dedicated
Supersededterminal phase forVirtualMachineOperation.Previously, a VMOP interrupted by a newer operation for the same VM was set to
phase: Completedwithconditions[Completed].reason: Superseded. This made superseded operations indistinguishable from successfully completed ones without inspecting condition details.Changes:
VMOPPhaseSupersededadded to the API enum and CRD schema (EN + RU docs).markSupersededin vmop service now setsstatus.phase=Supersededinstead ofCompleted.reason=Superseded→phase=Superseded.IsFinished()and all terminal phase checks across vm, vmop, metrics, CLI, and e2e now includeSuperseded.Supersededphase exposed in the status-phase metric;finishedAttimestamp recorded for superseded VMOPs;Supersededreason counted as a successful terminal reason.waitno longer hangs on superseded VMOPs; outputs asupersededmessage with condition details.Supersededstate.Why do we need it, and what problem does it solve?
When a user or automation creates a new VMOP that supersedes an in-flight one, the older VMOP appears as
Completed— the same phase as a successfully finished operation. Any tooling that checksphase == Completedas a success signal gets a false positive. A dedicated phase makes the terminal state unambiguous.What is the expected result?
status.phase: Supersededconditions[Completed].status: "True"conditions[Completed].reason: SupersededSupersededphase and record afinishedAttimestamp.Checklist
Changelog entries