diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 06b3385..8cf2c95 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -675,7 +675,14 @@ membership would both have failed. Applied to the NINE role nodes and deliberately NOT to the controller, which is exactly the Office1 pre-migration shape. Final tag state matches the old region row-for-row. - **THE CARVE IS THE REMAINING WORK, and it is now visible:** `enp1s0` is correctly + **PLANE IPAM COMPLETE ON THE NEW REGION -- NAMED GATE `dc-plane-ipam.sh check vr1-dc0` + = pass 24 / fail 0, EXIT 0** (capture `docs/audit/dc0-region-plane-ipam-20260730.txt`). + Applied with the EXISTING tool, no new code: 13 D-134 reserved bands + the FIP pool + (`10.12.5.0-10.12.7.254`), then the 5 missing v6 plane subnets, each created on the SAME + MAAS vlan as its v4 twin and READ BACK. The v6 half needs the NetBox apex, which is the + reason the voffice1->rack tunnel architecture exists. Its own forced sequencing held: the + `reserve` run SKIPPED every v6 band with "not in MAAS yet -- run carve-v6 first". + **WHAT REMAINS FOR THE CARVE, and it is now the ONLY thing between here and the deploy:** `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` and no subnet. That is exactly the 60 NIC re-homes + 9 `br-ex` bridges + 54 statics that diff --git a/docs/audit/dc0-region-plane-ipam-20260730.txt b/docs/audit/dc0-region-plane-ipam-20260730.txt new file mode 100644 index 0000000..30e7a77 --- /dev/null +++ b/docs/audit/dc0-region-plane-ipam-20260730.txt @@ -0,0 +1,47 @@ +dc0 PER-DC REGION -- PLANE IPAM COMPLETE (D-134 bands + R2 dual-stack) +Captured 2026-07-30. Region http://10.12.8.6:5240/ via profile vr1-dc0-region. +Applied: 13 reserved bands + FIP pool, then 5 v6 plane subnets (each created +on the SAME MAAS vlan as its v4 twin, and READ BACK). v6 needed the NetBox apex, +which is why the voffice1->rack tunnel architecture exists. +====================================================================== + +OK profile 'vr1-dc0-region' -> region with racks [hot-kid] (as expected) + +$ MAAS_PROFILE=vr1-dc0-region dc-plane-ipam.sh check vr1-dc0 +== dc-plane-ipam check vr1-dc0 == + apex record: netbox/draft/vr1-office1-current-20260725.json + +-- v4 planes (from lib-net) -- + [ok] v4 provider-public 10.12.4.0/22 present (fabric=vr1-dc0-provider-public) + [ok] v4 metal-admin 10.12.8.0/22 present (fabric=fabric-0) + [ok] v4 metal-internal 10.12.12.0/22 present (fabric=vr1-dc0-metal-internal) + [ok] v4 data-tenant 10.12.16.0/22 present (fabric=vr1-dc0-data-tenant) + [ok] v4 storage 10.12.32.0/22 present (fabric=vr1-dc0-storage) + [ok] v4 replication 10.12.36.0/22 present (fabric=vr1-dc0-replication) + +-- v6 planes (from the apex) -- + [ok] v6 data-tenant fd50:840e:74e2:230::/64 present + [ok] v6 metal-admin fd50:840e:74e2:220::/64 present + [ok] v6 metal-internal fd50:840e:74e2:221::/64 present + [ok] v6 provider-public 2602:f3e2:f02:10::/64 present + [note] provider-public 2602:f3e2:f02:11::/64 provider VIP block, MAAS subnet=no (not asserted) + [ok] v6 replication fd50:840e:74e2:250::/64 present + [ok] v6 storage fd50:840e:74e2:240::/64 present + +-- D-134 reserved bands (v4) -- + [ok] provider-public util band 10.12.4.4-10.12.4.49 reserved + [ok] provider-public vip band 10.12.4.50-10.12.4.99 reserved + [ok] metal-admin util band 10.12.8.4-10.12.8.49 reserved + [ok] metal-admin vip band 10.12.8.50-10.12.8.99 reserved + [ok] metal-internal util band 10.12.12.4-10.12.12.49 reserved + [ok] metal-internal vip band 10.12.12.50-10.12.12.99 reserved + [ok] data-tenant util band 10.12.16.4-10.12.16.49 reserved + [ok] data-tenant vip band 10.12.16.50-10.12.16.99 reserved + [ok] storage util band 10.12.32.4-10.12.32.49 reserved + [ok] storage vip band 10.12.32.50-10.12.32.99 reserved + [ok] replication util band 10.12.36.4-10.12.36.49 reserved + [ok] replication vip band 10.12.36.50-10.12.36.99 reserved + +RESULT: pass=24 fail=0 +PASS: dc-plane-ipam check vr1-dc0 + EXIT = 0 diff --git a/docs/changelog-20260730-dc0-region-migration.md b/docs/changelog-20260730-dc0-region-migration.md index 7e5d429..00dc83f 100644 --- a/docs/changelog-20260730-dc0-region-migration.md +++ b/docs/changelog-20260730-dc0-region-migration.md @@ -870,3 +870,28 @@ diff the rebuilt region against, and the missing tag would have surfaced as a deploy failure. **Revert.** `maas vr1-dc0-region tag update-nodes openstack-vr1-dc0 remove=` per node. + +--- + +## Item 24 -- plane IPAM completed with EXISTING tooling (no new code) + +**NAMED GATE: `MAAS_PROFILE=vr1-dc0-region dc-plane-ipam.sh check vr1-dc0` -> pass 24 / +fail 0, EXIT 0** (capture `docs/audit/dc0-region-plane-ipam-20260730.txt`). Before: pass 7 +/ fail 17. + +Two applies, both idempotent, dry-run first, every write read back: +- `reserve vr1-dc0 --commit` -> **13 applied, 0 errors**: the D-134 utility (`.4-.49`) and + VIP (`.50-.99`) bands on all six planes, plus the FIP pool `10.12.5.0-10.12.7.254` that + `phase-04-network-verify` asserts. +- `carve-v6 vr1-dc0 --commit` -> **5 applied, 0 errors**: the missing v6 plane subnets, each + created on the SAME MAAS vlan as its v4 twin and READ BACK on it. + +**The tool's own forced sequencing worked and is worth noting as a design that paid off:** +the `reserve` run SKIPPED every v6 band with `not in MAAS yet -- run carve-v6 first`, rather +than failing or silently doing nothing. Running the two in the wrong order is therefore safe. + +**This is also the step that justifies the tunnel architecture** (item 2): `carve-v6` derives +its prefixes from the NetBox apex record, which only voffice1 can reach, while the target +region is only reachable from the rack. Neither host alone could have run it. + +**Revert.** Delete the 5 v6 subnets and the 13 ipranges on the new region.