diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 083b70d..f2b907d 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -3074,6 +3074,36 @@ later one 6361). **A successful download would now fail HASH verification against the stale local Release** -- a different error from the timeout, not fixed by fixing the timeout. Whether debmirror re-fetches `Release` early enough each run to avoid this was NOT measured. + **>>> THE LAST OWED PRE-DEPLOY EXCHANGE IS CLOSED: D-139 STEP 6 RUNS IN FULL BEFORE THE + DEPLOY. <<<** **OPERATOR RULING 2026-08-02 (GA-R5), exact utterance: "Full step 6 first, + then deploy".** Full text and the measurement it rests on: + `### ORDERING RULING 2026-08-02 -- D-139 step 6 executes IN FULL before the Stage-5 deploy` + in `docs/design-decisions.md`. This is the exchange the 2026-08-01 ordering ruling + explicitly left owed ("needs its own GA-R5 exchange before Step 4"). + **THE 08-01 RULING'S STATED PREMISE IS NO LONGER TRUE, and the question was put on + re-measurement rather than on that text.** It reasoned that the VIP overlays "carry v6 VIPs + in the ULA range". MEASURED 2026-08-02: `overlays/vr1-dc0-vips.yaml` has **ZERO** `fd50:` + legs and 39 GUA legs; it was re-rendered onto GUA on 08-02 and the rack's staged copy + brought into line the same day. **The deploy INPUT is already correct; the residual coupling + is in the APEX only.** + **MEASURED APEX STATE** (`netbox/d139-gua-carve.py --dc vr1-dc0` dry run against the WORKING + apex `office1-netbox` 10.10.1.10:8000, DOCFIX-195): **`CREATE 0 | EXISTS 16 | + RETIRE-REPORT 9`**, dependents **26 ip-addresses / 0 ip-ranges**. Step 1 is fully applied + and idempotent. **The 26 were ENUMERATED, not inferred from the count:** all are VIP + records -- 13 in `fd50:840e:74e2:220::/64` (metal-admin) and 13 in `:221::/64` + (metal-internal), octets `::50`-`::62`. The other three retiring `/64`s (data-tenant, + storage, replication) hold **ZERO** addresses. + **CONSEQUENCE: THE STAGE-5 DEPLOY IS BLOCKED ON STEP 6 AND ON NOTHING ELSE IN THE D-139 + LIST.** Step 6 = create 26 GUA VIP addresses, delete 26 ULA VIP addresses, retire 9 ULA + prefixes. Steps 4, 5 and 7 stay sequenced AFTER the deploy (7 necessarily -- its + `network-get` prerequisite needs a deployed unit). **COST, stated because it is the argument + against the option chosen: it needs a repo tool with a DELETE path against the apex, which + this repo has deliberately never had** (`d139-gua-carve.py` refuses to delete BY DESIGN, and + that refusal is why the step-1 push was safe). It is therefore the largest new surface + introduced immediately before a deploy and must be built to the step-1 standard: + independently reviewed, dry-run first, assertions proven able to FAIL, and **CREATE strictly + before DELETE** so no window exists in which a live VIP is recorded nowhere. + **NOT YET BUILT -- the tool does not exist as of this entry.** - 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/design-decisions.md b/docs/design-decisions.md index 3a85374..69e4724 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -7360,3 +7360,64 @@ **A1 TEST (GA-R3):** admitted as a D-number because a Roosevelt build session would grep this before choosing how to manage its Juju layer, and because it decides what the deliverable runbooks look like. + +### ORDERING RULING 2026-08-02 -- D-139 step 6 executes IN FULL before the Stage-5 deploy + +**Not a change to ruling A or B, and not a new D-number** (GA-R3: execution ordering is OPS). +It is recorded here because it CLOSES the exchange that the `ORDERING RULING 2026-08-01` +above explicitly left owed: *"at least step 6 has a deploy coupling that this ruling does not +settle ... That needs its own GA-R5 exchange before Step 4, and is NOT inferred from this +ruling."* This is that exchange. + +**THE PREMISE THAT THE 08-01 RULING STATED IS NO LONGER TRUE, and the question was put on +re-measurement rather than on that text.** The 08-01 note reasoned that "the per-DC VIP +overlays carry v6 VIPs in the ULA range, so deploying after steps 1-3 alone would place a +cloud whose NODES are GUA while its declared v6 VIPs are still ULA". Measured 2026-08-02: +`overlays/vr1-dc0-vips.yaml` carries **ZERO** `fd50:` legs and 39 GUA legs +(`2602:f3e2:f02:11` x13, `f02:20` x13, `f02:21` x13). The overlay was re-rendered onto GUA on +2026-08-02 and the dc0 rack's staged copy was brought into line the same day. **The deploy +input is therefore already correct; the residual coupling is in the APEX, not the overlay.** + +**MEASURED STATE AT THE TIME OF THE RULING** (`netbox/d139-gua-carve.py --dc vr1-dc0`, dry +run, against the WORKING VR1 apex `office1-netbox` http://10.10.1.10:8000 per DOCFIX-195): + + CREATE 0 | EXISTS 16 | RETIRE-REPORT 9 + dependent objects inside the retiring prefixes: 26 ip-address(es), 0 ip-range(s) + +Step 1 is fully applied and idempotent. The 26 dependents were ENUMERATED rather than +inferred from the count: all 26 are VIP records, 13 in `fd50:840e:74e2:220::/64` +(metal-admin) and 13 in `fd50:840e:74e2:221::/64` (metal-internal), octets `::50`-`::62`, +described e.g. `VIP keystone metal-admin v6 (vr1-dc0) -- octet mirror ::50`. The other three +retiring `/64`s (data-tenant, storage, replication) hold **zero** addresses. + +**THE QUESTION AS PUT.** Nothing at deploy time reads the apex, so the divergence is +record-vs-reality and not a functional blocker -- but the apex would not know the GUA VIP +addresses are in use, so a later allocation from those `/64`s could hand out an address a VIP +already holds. No repo tool re-homes addresses: `d139-gua-carve.py`'s header is explicit -- +"Prefixes only: no addresses, no MAAS, and NO deletion ever." Options presented: (a) re-home +the 26 now and retire the prefixes later (split step 6); (b) deploy now with the whole of +step 6 deferred as a NAMED gate rather than a loose obligation; (c) full step 6 first, then +deploy. + +**Operator answer, exact utterance: "Full step 6 first, then deploy".** + +**CONSEQUENCE.** D-139 step 6 runs IN FULL before Step 4: create the 26 GUA VIP +ip-addresses, delete the 26 ULA VIP ip-addresses, and retire the 9 ULA prefix rows -- after +which the deploy lands on a fully consistent apex. **The Stage-5 deploy is BLOCKED on this** +and on nothing else in the D-139 list; steps 4, 5 and 7 remain sequenced after the deploy +(step 7 necessarily so -- its `network-get` prerequisite needs a deployed unit). + +**WHAT THIS COSTS, STATED PLAINLY BECAUSE IT IS THE ARGUMENT AGAINST THE OPTION CHOSEN.** It +requires a repo tool that this repo does not have and has deliberately never had: one with a +DELETE path against the apex. `d139-gua-carve.py` refuses to delete BY DESIGN, and that +refusal is why the step-1 push was safe to run. The new tool is therefore the largest new +surface introduced immediately before a deploy, and it must be built to the standard the +step-1 tool was: independently reviewed, dry-run first, its assertions proven able to FAIL, +and CREATE strictly before DELETE so that no window exists in which an address is recorded +nowhere. + +**ORDERING WITHIN STEP 6, which the ruling does not itself fix and which is taken as the +minimal safe reading:** create all 26 GUA records FIRST, verify, then delete the 26 ULA +records, then retire the 9 prefixes. Reversed, there would be an interval in which the apex +records no address for a live VIP -- the same orphaning hazard that DEFECT 3 of the +2026-08-01 CORRECTION NOTE identified for the prefixes.