Skip to content

feat(vmop): add superseded phase#2492

Merged
danilrwx merged 4 commits into
mainfrom
feat/vmop/add-superseded-phase
Jun 30, 2026
Merged

feat(vmop): add superseded phase#2492
danilrwx merged 4 commits into
mainfrom
feat/vmop/add-superseded-phase

Conversation

@danilrwx

@danilrwx danilrwx commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Description

Add a dedicated Superseded terminal phase for VirtualMachineOperation.

Previously, a VMOP interrupted by a newer operation for the same VM was set to phase: Completed with conditions[Completed].reason: Superseded. This made superseded operations indistinguishable from successfully completed ones without inspecting condition details.

Changes:

  • VMOPPhaseSuperseded added to the API enum and CRD schema (EN + RU docs).
  • markSuperseded in vmop service now sets status.phase=Superseded instead of Completed.
  • Lifecycle snapshot handler recovers the correct phase from conditions: reason=Supersededphase=Superseded.
  • IsFinished() and all terminal phase checks across vm, vmop, metrics, CLI, and e2e now include Superseded.
  • Metrics: Superseded phase exposed in the status-phase metric; finishedAt timestamp recorded for superseded VMOPs; Superseded reason counted as a successful terminal reason.
  • CLI wait no longer hangs on superseded VMOPs; outputs a superseded message with condition details.
  • Internal migration lifecycle doc updated with the Superseded state.

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 checks phase == Completed as a success signal gets a false positive. A dedicated phase makes the terminal state unambiguous.

What is the expected result?

  1. Create a VMOP for a VM.
  2. Create a second VMOP for the same VM, superseding the first.
  3. Verify the older VMOP shows:
    • status.phase: Superseded
    • conditions[Completed].status: "True"
    • conditions[Completed].reason: Superseded
  4. Verify CLI wait exits immediately on a superseded VMOP (does not hang).
  5. Verify metrics expose the Superseded phase and record a finishedAt timestamp.

Checklist

  • The code is covered by unit tests.
  • e2e tests passed.
  • Documentation updated according to the changes.
  • Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: api
type: feature
summary: "Add the Superseded phase for VirtualMachineOperation resources interrupted by a newer operation."

@danilrwx danilrwx added this to the v1.10.0 milestone Jun 16, 2026
@danilrwx danilrwx force-pushed the feat/vmop/add-superseded-phase branch from a62ae41 to 29ceb47 Compare June 16, 2026 07:40
@danilrwx danilrwx marked this pull request as ready for review June 16, 2026 07:40
@danilrwx danilrwx force-pushed the feat/vmop/add-superseded-phase branch 3 times, most recently from 432ee94 to f62e652 Compare June 29, 2026 15:53
danilrwx added 3 commits June 30, 2026 09:38
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>
@danilrwx danilrwx force-pushed the feat/vmop/add-superseded-phase branch from 005e659 to 3646946 Compare June 30, 2026 07:38
Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
@danilrwx danilrwx merged commit 4f6fd0b into main Jun 30, 2026
30 of 32 checks passed
@danilrwx danilrwx deleted the feat/vmop/add-superseded-phase branch June 30, 2026 11:23
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants