diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index b6d63b2..9b39d28 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2438,11 +2438,30 @@ the upstream's correctness. The 05:48 rack reboot otherwise recovered EVERYTHING reboot-persistent unaided: region API 200, mirror 200, snap proxy listening, juju controller connected. **The single casualty was the un-unitised tunnel.** - **STILL OWED BEFORE THE DEPLOY:** Step 3.5 (`add-model vr1-dc0` + spaces gate + - `apt-mirror`), then Step 4; and the UNRULED ordering question of whether D-139's apex - CREATE-only push precedes the bundle deploy -- deploying on the current ULA carve means - D-139 steps 2-6 later re-carve node addresses under a live cloud, the expensive path that - entry warns about since addresses bake into `agent.conf` at deploy time. + **>>> ORDERING RULED 2026-08-01 (GA-R5) -- THE D-139 GUA CARVE GOES BEFORE THE DEPLOY. + Operator answer, exact utterance: "Apex push AND the MAAS/node GUA carve, then deploy". <<<** + Full text and consequence: `### ORDERING RULING 2026-08-01 -- D-139 execution list vs the + Stage-5 deploy` in `docs/design-decisions.md`. **D-139 execution steps 1, 2 and 3 run BEFORE + the Stage-5 bundle deploy**, so the cloud is deployed ONCE on its final GUA addresses and + nothing is re-addressed underneath it. **The 2026-07-30 standing directive is satisfied in + SUBSTANCE rather than literally** -- the deploy remains the goal and nothing else is admitted + ahead of it, but it is sequenced after the carve that would otherwise have to be redone + through it. **This is NOT record-churn and must not be read as the GA-F06 failure mode:** it + is build work on the deploy's critical path, ruled by the operator against the alternative. + **NOT SETTLED BY THIS RULING, and stated so it is not inferred: D-139 steps 4-6** (Octavia v6 + SAN reissue + `lib-net.sh`'s v6 arm; the `lb-mgmt` VLAN/space/subnet; re-homing the 52 VIP + ip-addresses then retiring the ULA rows). **Step 6 has a deploy coupling this ruling does not + answer -- 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.** + That needs its own GA-R5 exchange before Step 4. Step 7 (v4 removal) is unchanged, still + `storage`+`replication` together, still gated on the unmeasured `network-get` question -- + which now arrives LATER, since the deploy that produces it is sequenced after the carve. + **STILL OWED BEFORE THE DEPLOY, in ruled order:** D-139 step 1 (apex CREATE-only push, + `netbox/d139-gua-carve.py --dc vr1-dc0 --commit`; tool built, independently reviewed, + dry-run byte-identical, `--commit` never yet passed), step 2 (MAAS GUA `/64`s alongside the + ULA), step 3 (node v6 re-carve WHILE v4 IS STILL PRESENT -- `dc-node-v6-carve.py` pivots on + IPv4 existing); the step 4-6 exchange above; then Step 3.5 (`add-model vr1-dc0` + spaces gate + + `apt-mirror` -- note the spaces gate reads MAAS subnets, which step 2 changes) and Step 4. - 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 31c25e9..0db42d8 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -7114,3 +7114,39 @@ **PREREQUISITE FOR STEP 7, STILL NOT TAKEN:** does `network-get` return a v6 address on a v6-only bound space? It needs a deployed unit, so it rides the next deploy. Step 7 must not start before it is answered. + +### ORDERING RULING 2026-08-01 -- D-139 execution list vs 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 sits against D-139's own execution list and against a +standing operator directive, and a future session would otherwise read the two as +conflicting). + +**The conflict, stated as it was put.** The 2026-07-30 standing directive reads "we have to +continue to juju deployment next session no matter what". D-139's replaced execution list +(the CORRECTION NOTE above) puts the apex push, the MAAS carve and the node re-carve BEFORE +anything else. Deploying first is cheapest now and yields the `network-get`-on-a-v6-only-space +measurement that step 7 is blocked on, since that needs a deployed unit -- but it means steps +2-6 later re-address nodes UNDER a live cloud, and D-139 records that addresses bake into every +unit's `agent.conf` at deploy time. + +**Operator answer, exact utterance: "Apex push AND the MAAS/node GUA carve, then deploy".** + +**CONSEQUENCE.** D-139 execution steps **1, 2 and 3** run BEFORE the Stage-5 bundle deploy, so +the cloud is deployed ONCE, on its final GUA addresses, and nothing is re-addressed underneath +it. The standing directive is thereby satisfied in substance rather than literally: the deploy +remains the goal and nothing else is admitted ahead of it, but it is sequenced after the carve +that would otherwise have to be redone through it. + +**INTERPRETATION STATED SO IT CAN BE CORRECTED RATHER THAN ASSUMED.** The options as presented +named steps 1-3. Steps **4-6** (Octavia v6 SAN reissue + `lib-net.sh`'s v6 arm; the `lb-mgmt` +VLAN/space/subnet; re-homing the 52 VIP ip-addresses and only then retiring the ULA rows) were +NOT put, and at least step 6 has a deploy coupling that this ruling does not settle: 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. That needs its own +GA-R5 exchange before Step 4, and is NOT inferred from this ruling. + +**Step 7 (v4 removal) is unchanged and still out of this list**, still scoped to `storage` + +`replication` together per the "B plus C" ruling, and still gated on the unmeasured +`network-get` question -- which now arrives later, since the deploy that produces it is +sequenced after the carve.