diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index f2b907d..bae951e 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -3104,6 +3104,30 @@ 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.** + **>>> AND "RETIRE" IS NOW DEFINED: IT MEANS DEPRECATE. NOTHING IS DELETED. <<<** + **OPERATOR RULING 2026-08-02 (GA-R5), taken in a SEPARATE exchange from the ordering ruling + -- exact utterance: "Deprecate both, delete nothing".** Full text: + `### AMENDMENT 2026-08-02 -- D-139 step 6: "retire" means DEPRECATE, and nothing is deleted` + in `docs/design-decisions.md`. **IT HAD TO BE ASKED, NOT INFERRED:** D-139 says "retire the + ULA rows" and this repo has never defined that for an IPAM OBJECT -- every `netbox/*.py` + importer uses only `active`/`container`/`reserved`, `deprecated` appears nowhere, and + `d139-gua-carve.py:4` says "NO deletion ever". Status choices were verified against the LIVE + API before the options were put: prefixes `['container','active','reserved','deprecated']`, + ip-addresses `['active','reserved','deprecated','dhcp','slaac']`. + **STEP 6 IS THEREFORE:** (1) CREATE 26 GUA VIP ip-addresses (`f02:20::50-::62` metal-admin, + `f02:21::50-::62` metal-internal) `status=active`; (2) set `status=deprecated` on the 26 ULA + VIP addresses; (3) set `status=deprecated` on the 9 ULA prefixes. **CREATE FIRST, VERIFY, + THEN DEPRECATE** -- reversed, there would be an interval in which the apex marks a live VIP's + only record unusable. + **THE COST THE ORDERING RULING FLAGGED IS WITHDRAWN.** That entry called step 6 "the largest + new surface introduced immediately before a deploy" because it needed a DELETE path the repo + has deliberately never had. **There is now NO delete path:** the tool is CREATE plus + STATUS-UPDATE only, the never-delete posture is preserved repo-wide, every step is reversible + by flipping a status back, and the ULA-to-GUA migration stays VISIBLE in the apex. + **NOTE FOR A LATER READER: `deprecated` is ADVISORY in NetBox, not enforcing** -- it does not + prevent an allocation, it signals one should not be made. The functional protection against + handing out an in-use GUA address comes from the 26 GUA records EXISTING, not from the + deprecation. - 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 69e4724..d74b145 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -7421,3 +7421,46 @@ 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. + +### AMENDMENT 2026-08-02 -- D-139 step 6: "retire" means DEPRECATE, and nothing is deleted + +**Operator ruling, taken in a SEPARATE exchange from the ordering ruling above** (GA-R5: one +decision per exchange -- the ordering ruling settled WHEN step 6 runs, this settles WHAT it +does). Not a new D-number: it defines a term inside an existing execution list (GA-R3, OPS). + +**WHY IT HAD TO BE ASKED RATHER THAN INFERRED.** D-139's execution list says "retire the ULA +rows in the apex and in MAAS", and this repo has NEVER defined what retire means for an IPAM +OBJECT. Measured: every `netbox/*.py` importer uses only `active`, `container` or `reserved` +-- `deprecated` appears nowhere -- and `d139-gua-carve.py:4` states "no addresses, no MAAS, +and NO deletion ever". So the word could equally have meant DELETE the rows or MARK them +unusable, and the two differ irreversibly in one direction. Verified against the LIVE API +before the options were put, rather than assumed from NetBox documentation: + + OPTIONS ipam/prefixes status -> ['container', 'active', 'reserved', 'deprecated'] + OPTIONS ipam/ip-addresses status -> ['active', 'reserved', 'deprecated', 'dhcp', 'slaac'] + +**Operator answer, exact utterance: "Deprecate both, delete nothing".** + +**CONSEQUENCE, and it materially shrinks the risk the ordering ruling flagged.** Step 6 is: + +1. CREATE the 26 GUA VIP ip-addresses (`2602:f3e2:f02:20::50-::62` metal-admin, + `2602:f3e2:f02:21::50-::62` metal-internal), `status=active`, descriptions mirroring the + ULA originals. +2. Set `status=deprecated` on the 26 ULA VIP ip-addresses. +3. Set `status=deprecated` on the 9 ULA prefix rows. + +**THERE IS NO DELETE PATH.** The ordering ruling recorded that step 6 "needs a repo tool with +a DELETE path against the apex, which this repo has deliberately never had" and called that +the largest new surface before a deploy. **That cost is now withdrawn:** the tool is +CREATE-plus-STATUS-UPDATE only, `d139-gua-carve.py`'s never-delete posture is preserved +repo-wide, and every step is reversible by flipping a status back. The ULA-to-GUA migration +also stays VISIBLE in the apex rather than vanishing from it. + +**ORDERING WITHIN STEP 6 IS UNCHANGED and still matters:** CREATE all 26 GUA records FIRST +and verify, THEN deprecate. Reversed, there would be an interval in which the apex marks a +live VIP's only record unusable. + +**NOTE FOR A LATER READER: `deprecated` is ADVISORY in NetBox, not enforcing.** It does not +prevent an allocation; it signals one should not be made. The functional protection against +handing out an in-use GUA address comes from step 1 above -- the 26 GUA records EXISTING -- +not from the deprecation.