diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 771ac83..02a3919 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -585,8 +585,10 @@ `cpu=8 mem=24576` (exact D-121 Option C storage-node shape), `power=virsh/off`, all six pinned MACs present. The sequence above is therefore a WORKING re-enrolment ordering, with the one nuance recorded below. - **RESOLVED -- A COMMISSION ISSUED IMMEDIATELY AFTER AN `abort` CAN LAND IN `New` ONCE; - RE-ISSUING IT SUCCEEDS.** Attempt 2 passed every script and still went to `New`; attempt 3, + **^ SUPERSEDED BY A STRONGER RESULT (batch 1, below): the `New` detour was caused by + ORDERING -- commissioning a machine whose `power_type` was still unset -- not by chance. + Original text kept as the reasoning that got there:** **A COMMISSION ISSUED IMMEDIATELY + AFTER AN `abort` CAN LAND IN `New` ONCE; RE-ISSUING IT SUCCEEDS.** Attempt 2 passed every script and still went to `New`; attempt 3, issued under IDENTICAL conditions from a settled `New`, reached `Ready` in ~3.5 min (which matches the dc1 standup timing). So it was a ONE-OFF, not systematic -- and the repeat was justified precisely because it was the experiment that DISTINGUISHED those two cases, not a @@ -638,6 +640,20 @@ remains uncharacterised beyond concurrency; the canary is direct evidence that low concurrency works and the migration does not need the root cause to proceed. **LOGGED for the dc1 standup and Roosevelt: do not power on a whole rack for enlistment at once.** + **BATCHED RE-ENROLMENT WORKS AND PINS THE ROOT CAUSE. Batch 1 (control-01/02/03) enlisted + in 2.3 MINUTES** against the 15-minute zero-record stall for nine, **and all three went + straight to `Ready` with NO `New` detour** -- because their power config was set BEFORE + `commission` was issued, where the canary was commissioned first and powered afterwards. + That supersedes the "one-off" reading: the detour is CAUSED BY ORDERING. **Revised standing + procedure: `delete -> virsh start -> self-enlist -> SET POWER -> abort -> commission`, and + NEVER issue `commission` on a machine whose `power_type` is unset.** Enlist in batches of + three. Region now holds **4 machines, all `Ready`** (`civil-bug` storage-04, `mint-roughy` + control-01, `gentle-raven` control-02, `square-insect` control-03), each matched to its + libvirt domain by pinned MAC. + **ROLE TAGS NEED NO NEW TOOL:** the region carries only `openstack-vr1-dc0` + `virtual`, + but `maas-role-tags.sh` CREATES `control`/`compute`/`storage`/`juju-controller-vr1-dc0` + (`:38`, `:125`, `:184`) -- and it REFUSES while any pinned boot MAC has no MAAS record, so + it cannot run before all ten are enlisted. The gate enforces the ordering by itself. **THE CANARY'S CARVE IS THE REMAINING WORK, and it is now visible:** `enp1s0` is correctly on `fabric-0` (metal-admin -- it PXE'd there) with an AUTO link on `10.12.8.0/22`, while `enp2s0..enp6s0` each landed on a FRESH auto-created fabric (`fabric-7..11`) with `link_up` diff --git a/docs/changelog-20260730-dc0-region-migration.md b/docs/changelog-20260730-dc0-region-migration.md index f3ae4cc..deec2f6 100644 --- a/docs/changelog-20260730-dc0-region-migration.md +++ b/docs/changelog-20260730-dc0-region-migration.md @@ -783,3 +783,43 @@ evidence that low concurrency works, and the migration does not need the root cause to proceed. **LOGGED for the dc1 standup and for Roosevelt: do not power on a whole rack of nodes for enlistment at once.** + + +--- + +## Item 21 -- BATCHED RE-ENROLMENT WORKS, and it confirms the ordering was the cause + +**Batch of three (control-01/02/03): enlisted in 2.3 minutes** against a 15-minute stall +with zero records for nine. Batching is the working procedure. + +**The more useful result: all three went straight to `Ready` with NO `New` detour.** The +canary needed a second commission; these did not. The difference is that their power config +was set BEFORE `commission` was issued, whereas the canary was commissioned first and had +power set afterwards. So the canary's detour was **caused by the ordering, not by chance** -- +which is a stronger and more useful conclusion than the earlier "one-off", and it supersedes +it. + +**REVISED per-node procedure, now evidenced twice:** + + delete (old region) -> virsh start -> self-enlist -> SET POWER -> abort -> commission + +with the emphasis on power BEFORE commission. Issue `abort` only to clear the wedge left by +the enlistment-time commissioning; once power is set first, `commission` completes in one +pass (~3.5 min for three concurrent). + +**Standing guidance for dc1 and Roosevelt:** enlist in batches of three, and never issue +`commission` on a machine whose `power_type` is still unset. + +--- + +## Item 22 -- role tags: covered by existing tooling, ordering enforced by the tool itself + +The new region carries only `openstack-vr1-dc0` (created by `dc-region-topology.sh`) and +MAAS's own `virtual`. The `control` / `compute` / `storage` / `juju-controller-vr1-dc0` tags +do NOT exist yet -- but `scripts/maas-role-tags.sh` CREATES them (`ROLES` at `:38`, +`ROLES+=("juju-controller-$SITE")` at `:125`, creation at `:184`), so task 7's tagging needs +no new tool. + +**Its own refusal enforces the correct ordering:** it refuses if any pinned boot MAC has no +MAAS record, so it cannot run until all ten machines are enlisted. That is the gate working +in the right direction -- no additional sequencing discipline required from the operator.