mirror of
https://github.com/vatesfr/xen-orchestra.git
synced 2026-10-12 02:24:05 +00:00
Mathieu
9f337ace71
* feat(xo-server,rest-api,xo-web/rpu): persist a recovery record across restarts
A rolling pool update now writes a `rpuRecovery` record (LevelDB, one per
pool) before its first side effect and keeps it updated during the run:
operator options, update variant, host order, initial VM placement, per-host
step statuses, last filtered error, and the pinned VMs shut down for their
host's reboot (previously only tracked in memory, so an xo-server crash left
them halted with nothing to restart them). A record left in a live status at
xo-server boot is flipped to `interrupted`; a successful run deletes its
record; an unreadable or unknown-version record is reported as `blocked`
without touching the stored value.
The status is exposed through `pool.getRollingUpdateRecovery` and
`GET /rest/v0/pools/{id}/rolling_update_recovery` (filtered view: never the
raw intent, reusing the existing pool permissions), and the pool Patches tab
in XO5 shows a warning with per-host progress, the last error and the pinned
VMs still halted.
First card of the RPU resume-after-failure spike: the record only reports
for now, resuming an interrupted run comes separately.
* docs(changelog): entry for the RPU recovery record (#10331)
* fix(xo-server,rest-api,xo-web/rpu): updates after review
* test(xo-server/rpu): cover the recovery record during the migrate back phase
The migrate back phase now retries the rejected migrations before giving
up, so a host is only recorded as failed once the retry passes are over,
and a pool which opted out of the phase must still close its `restoreVms`
steps, otherwise a finished run reads as still running in the record.
Both are asserted through a recorder spying on the step transitions.
* fix(xo-server/rpu): keep per-key reads in the recovery reconciliation
* test(xo-server/rpu): stub the recovery recorder in the rolling pool update tests
Since #10313, XenServers.rollingPoolUpdate runs the backup guard itself and
its tests drive it with a fake app. With the recovery record, the run also
calls app.startRpuRecoveryRun, which the fake app did not have.
The stub records its call, so the tests also check that a refusal from the
backup guard leaves no record behind.
* fix(xo-server/rpu): do not fail a successful run when its record cannot be deleted