diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 748bce5..d8a29d3 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1877,6 +1877,31 @@ 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. +- **ALL FOUR REMAINING GATED TASKS PROCESSED 2026-07-29 (operator: "Commission and process all + the listed tasks"). THE STAGE-5 ALLOCATION BLOCKER IS CLOSED.** + **(a) MAC adoption applied FIRST**, while the VMs were idle -- commissioning power-cycles them + and an in-place domain update must not race that. Both roots `0 add / 1 change / 0 destroy` + with ZERO creates/destroys; then **MAC drift 0 across all 20 nodes** and both roots re-plan + **"No changes"**. The pins are now REAL IN STATE -- until this apply the config asserted them + but state did not record them, so they protected nothing. + **(b) Both controllers commissioned on the DEFAULT path** (deliberately NOT + `skip_networking=1` -- unlike the storage nodes they had no config to preserve). Both + `New -> Ready in ~200s`. **Power control was the only thing missing**, confirming the item-42 + diagnosis by measurement rather than assertion. + **(c) `maas-role-tags.sh` extended to own the D-104 controller tag** -- the controller carries + its OWN tag and NO role tag, so a bootstrap constrained on `tags=juju-controller-` targets + it deterministically. Done IN THE SCRIPT rather than as two one-off commands **because the + 2026-07-29 ruling makes these assignments travel to every DC** -- a one-off command does not. + Harness 11 -> 12 (T10 re-pointed, T10b added so a missing controller tag is gated like the + three role tags). + **(d) All ruled tags created and applied, every write READ BACK.** dc0 created all four; dc1 + correctly reused the three GLOBAL role tags and created only `juju-controller-vr1-dc1`. + **INDEPENDENTLY VERIFIED from MAAS, not from script output: fleet 22 = 20 Ready + 2 Deployed + (NO `New` remaining); control 6 / compute 4 / storage 8 / juju-controller-vr1-dc0 1 / + juju-controller-vr1-dc1 1 / openstack-vr1-dcN 9 each.** `maas-role-tags check` PASSES on both + DCs. **Every tag the bundle machines block constrains on now exists and is applied**, which + was the loud-but-blocking allocation failure the chain audit measured. + Gauntlet **ALL GREEN (87) on vcloud**; repo-lint 0 fail. - **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 70b02fd..a19890f 100644 --- a/docs/changelog-20260728-vip-arity-gate.md +++ b/docs/changelog-20260728-vip-arity-gate.md @@ -1077,3 +1077,60 @@ 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. + +## 43. LIVE: MAC adoption applied, both controllers commissioned, all ruled MAAS tags created + +Operator: **"Commission and process all the listed tasks."** Four gated mutations, sequenced +deliberately. + +**(a) MAC adoption FIRST, while the VMs were idle** -- commissioning power-cycles them and an +in-place domain update must not race that. Both roots `0 add / 1 change / 0 destroy`, ZERO +creates and ZERO destroys in the saved plan. Then the checkpoint: **MAC drift 0 across all 20 +nodes** (10 per DC) and **both roots re-plan "No changes"**. The pins are now real in state -- +until this apply, the config asserted them but state did not record them, so they protected +nothing. + +**(b) Both controllers commissioned on the DEFAULT path** -- deliberately NOT +`skip_networking=1`, because unlike the storage nodes they had no configuration to preserve. +Both `New -> Ready in ~200s`, the same figure as every other node on this fleet. **Power +control was the only thing missing**, which confirms the diagnosis in item 42 rather than +merely asserting it. + +**(c) `maas-role-tags.sh` extended to own the D-104 controller tag** -- see item 44. + +**(d) All ruled tags created and applied, every write READ BACK.** dc0 created all four tags; +dc1 correctly found `control`/`compute`/`storage` already present (they are global) and +created only `juju-controller-vr1-dc1`. Twenty nodes tagged. + +**Independently verified from MAAS, not from the script output:** +``` +fleet: 22 {Deployed: 2, Ready: 20} <- no New remaining +control 6 | compute 4 | storage 8 | juju-controller-vr1-dc0 1 | juju-controller-vr1-dc1 1 +openstack-vr1-dc0 9 | openstack-vr1-dc1 9 +``` +`check` returns PASS on both DCs. **The Stage-5 allocation blocker is closed:** every tag the +bundle machines block constrains on now exists and is applied. + +**Revert.** `maas admin tag delete ` removes a tag; `tag update-nodes remove=` +un-tags a node. The MAC adoption reverts by removing the `macs` lists and re-applying. +Commissioning is idempotent. + +## 44. maas-role-tags now owns the controller tag -- because the ruling says assignments travel + +The per-DC Juju controller carries its OWN tag and NONE of the role tags, so a bootstrap +constrained on `tags=juju-controller-` targets it deterministically and no OpenStack role +constraint can cross-grab it. The script previously SKIPPED it as "not a role node"; it now +emits that tag as the host role, so every stage -- existence check, NEED/HAS, apply, read-back +-- handles it with no special case. + +**Doing this in the script rather than as two one-off `maas` commands is a direct consequence +of the 2026-07-29 ruling that these assignments follow ALL DC deployments.** A one-off command +does not travel to the next standup; a site-keyed script does. + +T10 re-pointed (the controller is TAGGED, not skipped) and **T10b added so a missing +controller tag is gated exactly like the three role tags**. Harness 11 -> 12. + +**OWNED:** my first attempt put an apostrophe (`host's`) inside the single-quoted shell string +wrapping the embedded python, so bash parsed python and all 11 cases failed at once. Reworded; +that block now carries no apostrophes. Worth recording -- it is a quoting trap specific to +embedding python in these scripts, and it fails loudly but confusingly.