diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 4924faf..748bce5 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1856,6 +1856,27 @@ **NEXT, all gated:** `maas-node-power.sh` -> `power_type=virsh` on both controllers; commission them (DEFAULT path -- no `skip_networking`, since there is nothing to preserve); create the `juju-controller-` tags; and `maas-role-tags.sh apply --commit` for the role tags. +- **voffice1 PULLED CURRENT and `power_type=virsh` SET on both controllers, 2026-07-29.** + Pull `c9cc79f` -> `75e3657`; both inner tfstates confirmed gitignored BEFORE and sha256 + BYTE-IDENTICAL after (the Phase-0 safety proof, since those files are the substrate's + state-of-record and live inside the working tree). Power set scoped to `vr1-dcN-juju`, so the + nine already-configured role nodes per DC were NOT re-touched; both verified by a real + `query-power-state` -> `off`, which is ground truth (a stored parameter is not power control). + **A diff the pull revealed, explained not waved through: both inner roots now plan + `0 add / 1 change / 0 destroy` -- that is MAC ADOPTION, not drift.** The plan adds + `mac = { address = ... }` blocks carrying values IDENTICAL to live, because tofu state has no + `mac` block for a domain created unpinned; the 2026-07-21 shape exactly. **NOT applied** -- + a separate gated in-place update on a running domain. + **WHY `power_type` WAS NOT SET DURING COMMISSIONING (operator question, answered with + evidence):** (1) these machines were **never commissioned** -- `New` is post-enlistment, + pre-commissioning, and those are distinct phases; (2) even commissioned, MAAS auto-configures + power only for **IPMI-based** machines, by probing the BMC in-band -- evidenced by this MAAS's + own CLI, `:param skip_bmc_config: ... for IPMI based machines`. A KVM guest has NO BMC, and the + virsh parameters (qemu+ssh URI, credential, libvirt DOMAIN NAME) are facts about the + HYPERVISOR that nothing inside the guest can discover. **That is the chicken-and-egg behind the + 2026-07-20 incident** -- commissioning needs power control, but for a virsh VM power config + cannot be discovered BY commissioning. Structural, already known to the repo, and the only gap + was that nobody had run the step for two brand-new machines. - **THREE PLATFORM BEHAVIOURS GRADUATED to `references/platform-traps.md`** at session close, having been recorded only in this status document (which is consolidated over time, so a durable trap does not belong here alone): MAAS auto-reserves `::1`-`::ffff:ffff` on EVERY diff --git a/docs/changelog-20260728-vip-arity-gate.md b/docs/changelog-20260728-vip-arity-gate.md index 6040f77..70b02fd 100644 --- a/docs/changelog-20260728-vip-arity-gate.md +++ b/docs/changelog-20260728-vip-arity-gate.md @@ -1028,3 +1028,52 @@ with MACs pinned. Gated next steps: set `power_type=virsh`; commission them on the DEFAULT path (no `skip_networking` -- nothing to preserve); create the `juju-controller-` tags; run `maas-role-tags.sh apply --commit`. + +## 41. voffice1 pulled current; power_type=virsh set on both controllers + +**Pull.** `c9cc79f` -> `75e3657`. Both inner tfstates confirmed `git check-ignore`-IGNORED +BEFORE the pull and sha256 **BYTE-IDENTICAL** after -- the same safety proof Phase 0 used, +because those files are the substrate's state-of-record and live inside the working tree. + +**A diff the pull revealed, explained rather than waved through.** Both inner roots now plan +`0 add / 1 change / 0 destroy`. That is **MAC ADOPTION, not drift**: the plan adds +`mac = { address = ... }` blocks carrying values IDENTICAL to what is already live, because +tofu's state has no `mac` block for a domain that was created unpinned. Exactly the +2026-07-21 shape (`0/9/0, 54 mac adoptions, ZERO replaces`). **NOT applied** -- it is a +separate gated in-place update on a running domain, and "set power_type" did not authorise it. + +**Power set, scoped narrowly.** `maas-node-power.sh --commit vr1-dcN-juju` -- the +prefix glob matches ONLY `vr1-dcN-juju-01`, so the nine already-configured role nodes per DC +were not re-touched. Both verified by a real `query-power-state`: + `[ok] moved-troll -> vr1-dc0-juju-01 (power state: off)` + `[ok] square-ferret -> vr1-dc1-juju-01 (power state: off)` +That read-back is the ground truth -- a stored parameter is not power control; querying the +driver proves MAAS can actually reach it. + +## 42. WHY power_type was not set during commissioning -- answered, with evidence + +Operator question. Two reasons, the first simpler than the second: + +**(1) These machines were never commissioned.** They are in `New`, which is POST-enlistment +and PRE-commissioning. Enlistment (PXE -> MAAS registers the machine) and commissioning (the +hardware-discovery run) are distinct phases. There was no commissioning pass in which +anything could have been set. + +**(2) Even commissioned, MAAS would not have set it, and structurally cannot.** MAAS +auto-configures power during commissioning only for IPMI-based machines, by probing the BMC +in-band from the ephemeral environment. Evidence from THIS MAAS's own CLI +(`maas admin machine commission --help`): + + :param skip_bmc_config: Optional. Whether to skip + re-configuration of the BMC for IPMI based machines. + +A KVM guest has no BMC to probe. And the virsh power parameters -- the `qemu+ssh://` URI, the +SSH credential, and the libvirt DOMAIN NAME -- are facts about the HYPERVISOR, entirely +outside the guest. Nothing running inside the VM can discover them. + +**That is the chicken-and-egg behind the 2026-07-20 incident:** commissioning needs power +control (MAAS power-cycles the machine to run the ephemeral env), but for a virsh VM the +power config cannot be discovered BY commissioning. It must be set out-of-band first. Which +is exactly why `maas-node-power.sh` exists and why D-103/D-123 ruled per-machine +`power_type=virsh` over a MAAS pod. So this was never a failure -- it is structural, the repo +already knew it, and the only gap was that nobody had run the step for two brand-new machines.