|
Canary re-enrolment: the ordering a fresh region actually needs
Canary xqqwdq/moral-salmon = vr1-dc0-storage-04 (a storage node, least central of the ten). Office1 23 -> 22; it re-enlisted into the new region carrying boot MAC 52:54:00:2b:ed:ab -- the machine that arrived is the machine that left. system_id AND hostname are both re-minted (xqqwdq -> 6q4syf, moral-salmon -> civil-bug), so the boot MAC is the only stable key; the pre-delete snapshot records it as the identity. MEASURED ORDERING, not the obvious one: a freshly-enlisted machine has no power config, so MAAS cannot power-cycle it and cannot drive commissioning. delete -> power on BY HAND via virsh -> self-enlist -> SET POWER -> abort -> commission. Skipping the power step wedges the machine in Commissioning producing zero events, because the enlistment ephemeral powers the node off and nothing can bring it back. maas-node-power.sh already supports the split the migration needs: VIRSH_URI enumerates from voffice1 over the transit /30 while the positional address stores what the REGION dials over metal-admin. Result was a real query-power-state, proving the region drives the rack's libvirt with the SEC-012 key in its snap. Found: the per-node serial log stopped capturing on 2026-07-21 while the domain XML still configures append-mode logging. It contains a complete, plausible boot that I read as current and reported as fact before checking the mtime. An append log that silently stopped appending returns confident, well-formed, wrong evidence. Logged, not actioned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/audit/dc0-premigration-machine-identity-20260730.txt 0 → 100644 |
|---|
| docs/changelog-20260730-dc0-region-migration.md |
|---|