diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 6289938..a64b5d0 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -3166,6 +3166,39 @@ be a blind cleanup. **MAAS has no `deprecated` status for a subnet** -- the choice is delete or leave -- so this is a SEPARATE operator decision and is NOT covered by the "Deprecate both, delete nothing" ruling, which was put and answered about the APEX. + **>>> D-139 STEP 6 IS EXECUTED. THE APEX HALF IS APPLIED AND 4 OF 5 MAAS ULA SUBNETS ARE + GONE; ONE IS DELIBERATELY HELD. <<<** **OPERATOR APPROVAL 2026-08-02, exact utterance: + "Queue up the MAAS half to run after you complete netbox. I approve the MAAS deletes to + clean up the data and config. Go ahead with both now".** + **APEX: applied, exit 0** -- `CREATE 26 | ALREADY 0 | DEPRECATE-ADDR 26 | DEPRECATE-PFX 9`, + both read-backs OK, and INDEPENDENTLY re-verified rather than taken on the tool's word: a + re-run reports `CREATE 0 | ALREADY 26 | DEPRECATE-ADDR 0 | DEPRECATE-PFX 0`, fully + idempotent. **NOTE FOR A LATER READER:** `d139-gua-carve.py` still reports `dependent + objects ... 26 ip-address(es)` -- CORRECT, because the ULA records still EXIST, deprecated + not deleted. The carve tool counts existence, not status; it is NOT evidence step 6 did + not run. + **>>> VERIFY-BEFORE-MUTATE FOUND A REAL HAZARD AND THE FIFTH SUBNET WAS NOT DELETED. <<<** + The approval was given before anyone knew WHAT `fd50:840e:74e2:220::/64` held. MEASURED: + `::5` STICKY user `juju-vr1-dc0` (the JUJU CONTROLLER) and `::6` STICKY user `MAAS` (the + MAAS REGION VM ITSELF) -- **and they have NO GUA counterpart.** The GUA metal-admin subnet + holds exactly nine entries, the nine tagged ROLE NODES (`::100-102`, `::120-121`, + `::150-153`), matching the record that `dc-node-v6-carve.py` walks only those nine and + that the controller's v6 was "restored separately" -- on ULA, never migrated. **Deleting + it would remove the only recorded v6 of the deploy client AND of the region the delete is + issued to.** HELD, pending its own decision; that is outside what the approval could have + meant. + **THE FOUR EMPTY ONES WERE PROVEN SAFE TWICE:** zero allocations AND **zero + machine-interface links** across all five -- the stronger check, since "no allocated IP" + does not mean "nothing references it". Zero links also CONFIRMS D-139 step 3 succeeded. + Deleted INDIVIDUALLY with a fresh re-check before each, never looped (hard rule 3; this + repo has a logged incident from batching nine deletes): `9` `:221::/64` metal-internal, + `8` `:230::/64` data-tenant, `12` `:240::/64` storage, `11` `:250::/64` replication, all + rc=0. **POST-STATE MEASURED:** six GUA `/64`s remain, one ULA held; machines unchanged at + **9 Ready + 1 Deployed**, total 10. + **STILL OPEN:** the held subnet -- migrate the controller/region v6 to GUA then delete, or + delete and accept losing those records, or leave it. **AND: NO REPO TOOL EXISTS for the + MAAS half** -- these were hand-issued `maas subnet delete` calls, so the dc1 rebuild + cannot reproduce them. Owed, not built. - Project: Omega Cloud, VR1 DC-DC rehearsal -- a two-DC + Office1-headend virtual rehearsal on KVM (vcloud host), rehearsing the future bare-metal Roosevelt deployment (D-100, `docs/design-decisions.md:1946`). diff --git a/docs/changelog-20260802-queued-items.md b/docs/changelog-20260802-queued-items.md index 4a83c4e..7d0653f 100644 --- a/docs/changelog-20260802-queued-items.md +++ b/docs/changelog-20260802-queued-items.md @@ -537,3 +537,75 @@ `docs/audit/d139-step6-tool-review-20260802.txt` (new), plus the two doc corrections. - **Revert:** delete the tool, its harness dir and the manifest line; re-run `bash scripts/run-tests-all.sh --record-manifest`. Nothing was written to the apex. + +## Item 11 -- D-139 STEP 6 EXECUTED: apex applied, and 4 of 5 MAAS ULA subnets removed + +**OPERATOR APPROVAL, exact utterance: "Queue up the MAAS half to run after you complete +netbox. I approve the MAAS deletes to clean up the data and config. Go ahead with both +now".** + +**THE APEX HALF IS APPLIED, exit 0.** `d139-step6-vip-rehome.py --dc vr1-dc0 --commit`: +`CREATE 26 | ALREADY 0 | DEPRECATE-ADDR 26 | DEPRECATE-PFX 9`, both read-backs OK. +INDEPENDENTLY VERIFIED after the fact, not on the tool's own word: a re-run reports +`CREATE 0 | ALREADY 26 | DEPRECATE-ADDR 0 | DEPRECATE-PFX 0` -- fully idempotent and +converged. + +**RECORDED SO A LATER READER IS NOT MISLED:** `d139-gua-carve.py` STILL reports +`dependent objects ... 26 ip-address(es)`. That is CORRECT and expected -- the 26 ULA +records still EXIST, deprecated rather than deleted, per the ruling. The carve tool counts +existence, not status. It is not evidence that step 6 did not run. + +**THE MAAS HALF: FOUR SUBNETS DELETED, ONE DELIBERATELY HELD.** + +**VERIFY BEFORE MUTATE FOUND A REAL HAZARD, and it is why the fifth was not deleted.** The +approval was given before anyone knew WHAT the `fd50:840e:74e2:220::/64` allocations were. +Measured: + +``` +fd50:840e:74e2:220::5 alloc_type=1 (STICKY) user=juju-vr1-dc0 <- the Juju controller +fd50:840e:74e2:220::6 alloc_type=1 (STICKY) user=MAAS <- the MAAS region VM +``` + +**And they have NO GUA counterpart.** The GUA metal-admin subnet holds exactly nine +entries -- `::100,::101,::102` control, `::120,::121` compute, `::150-::153` storage -- the +nine tagged ROLE NODES and nothing else. This matches the record that `dc-node-v6-carve.py` +walks only the nine tagged role nodes and that the controller's own v6 was "restored +separately" -- restored on ULA, never migrated. **So deleting that subnet would remove the +only recorded v6 address of the deploy client AND of the MAAS region the delete is issued +to.** That is not cleanup, and it is outside what the approval could have meant. HELD, +pending its own decision. + +**THE FOUR EMPTY ONES WERE SAFE, and that was established twice over.** Zero allocations +AND **zero machine-interface links** for all five ULA subnets -- the stronger check, since +"no allocated IP" does not by itself mean "nothing references it". Zero links also +CONFIRMS D-139 step 3 succeeded: the nine role nodes are fully on GUA. + +Deleted INDIVIDUALLY, never looped -- hard rule 3 forbids batching destructive steps, and +this repo has a logged incident from exactly that (2026-07-30, nine deletes in a loop; the +guard stopped it). Each got a fresh cidr + allocation re-check immediately before its own +delete: + +``` +subnet 9 fd50:840e:74e2:221::/64 metal-internal allocations=0 deleted rc=0 +subnet 8 fd50:840e:74e2:230::/64 data-tenant allocations=0 deleted rc=0 +subnet 12 fd50:840e:74e2:240::/64 storage allocations=0 deleted rc=0 +subnet 11 fd50:840e:74e2:250::/64 replication allocations=0 deleted rc=0 +``` + +**POST-STATE, MEASURED:** six GUA `/64`s remain (`f02:10/20/21/30/40/50`), one ULA remains +(`fd50:840e:74e2:220::/64`, id=2, held). Machines unchanged and healthy: **9 Ready + 1 +Deployed** (the controller), total 10. + +**STILL OPEN, needs a decision:** the held subnet. Options are to migrate the controller's +and region's v6 to GUA first and then delete, or to delete and accept losing those two +records, or to leave the subnet in place indefinitely. NOT decided here. + +**NO REPO TOOL EXISTS for the MAAS half** -- these were hand-issued `maas subnet delete` +calls. If the dc1 rebuild is to be reproducible, this belongs in a script with the same +emptiness + link preconditions asserted, and that is registered as owed rather than built. + +- Changed: live apex (26 created, 35 deprecated) and the dc0 MAAS region (4 subnets + deleted). Repo: this changelog + CURRENT-STATE. +- **Revert:** apex -- flip the 35 statuses back (the 26 creates are additive and wanted). + MAAS -- the four subnets can be recreated (`dc-region-topology.sh` carries the shape), + but their identities are gone; they held nothing, so nothing else is lost.