diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 2ce1569..f59a516 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -617,8 +617,26 @@ checks `cluster_count` NOWHERE -- which is why decorative HA was found by audit rather than by gate. R4's band ruling already covers the overlay's growth from 27 to ~55 LXD units, so address demand is not an argument against it. - Remaining: R7-R11 blocking (R11 next by the R6 sequencing), R12-R15 standing -- all - measured. + **R11 RULED 2026-07-27 -- exact utterance "Both full triples (.61 vault, .62 designate), + dual-family, and fix the gate (Recommended)"**, recorded as a **D-020 AMENDMENT + (2026-07-27)**. **Vault was ALREADY RULED and never built**: D-020's decision text + enumerates vault by name among the clustered apps carrying BOTH a provider and a metal + VIP, and measured base `vault` has an EMPTY options block. That is the SECOND ruled + decision this audit found unimplemented (the first being D-134's bands, R4). designate is + genuinely new -- absent from D-020's enumeration -- and this amendment ADDS it; its + `dnsaas` endpoint is already bound `provider-public`, so a provider leg is coherent. + Shape: the ESTABLISHED provider/admin/internal triple, at the next free octets in a + consecutive map (keystone `.50` ... ceph-radosgw `.60`) -- **vault `.61`, designate + `.62`**, DUAL-FAMILY per R2. Refused option (b), vault metal-only per the 2026-07-25 + expansion review: it contradicts D-020's own enumeration and would make vault the single + non-triple in the bundle; the conflict is recorded so that proposal is not later mistaken + for the ruled position. Mechanical consequences: `OCTET_LO/HI` in + `provider-bundle-check.py` and `VIP_OCTET_MAX` in `lib-net.sh` widen `.60` -> `.99` + (SEPARATELY NAMED, a two-file change), and `VIP_COUNT_EXPECT` 11 -> 13. **Gate hardening + ruled IN SCOPE, not deferred**: the checker learns to FAIL on an hacluster relation with + no VIP, because `cluster_count` is checked NOWHERE today and a 3->1 rewrite of all 20 + values produces a byte-identical PASS. Per R6 these VIPs land BEFORE the HA overlay. + Remaining: R7-R10 blocking, R12-R15 standing -- all measured. - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B diff --git a/docs/audit/queued-rulings-20260727.md b/docs/audit/queued-rulings-20260727.md index 9dc2f45..34e7ed8 100644 --- a/docs/audit/queued-rulings-20260727.md +++ b/docs/audit/queued-rulings-20260727.md @@ -483,7 +483,17 @@ - **(c)** Deploy them without VIPs deliberately (recording why consumers reaching a unit address is acceptable here). -OPERATOR UTTERANCE: +OPERATOR UTTERANCE: **"Both full triples (.61 vault, .62 designate), dual-family, and +fix the gate (Recommended)"** -- RULED 2026-07-27. **R11 IS CLOSED.** Recorded as a +**D-020 AMENDMENT (2026-07-27)**. Key finding from measuring first: **vault was ALREADY +RULED and never built** -- D-020 enumerates it by name as carrying both a provider and a +metal VIP, and base vault has an EMPTY options block. Second ruled-but-unbuilt decision +this audit found, after D-134's bands. designate is genuinely new (absent from D-020) and +is ADDED. Octets `.61`/`.62` continue a consecutive map ending at ceph-radosgw `.60`. +Refused (b) vault-metal-only: contradicts D-020's enumeration and makes vault the only +non-triple. Mechanical: `OCTET_LO/HI` and `VIP_OCTET_MAX` widen to `.99` (two separately +named constants, two files), `VIP_COUNT_EXPECT` 11 -> 13. Gate hardening ruled IN SCOPE -- +the checker learns to fail on hacluster-without-VIP. --- diff --git a/docs/design-decisions.md b/docs/design-decisions.md index bba81e6..d1f8658 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -401,6 +401,65 @@ --- +## D-020 -- AMENDMENT (2026-07-27): vault's VIP is BUILT, designate JOINS the enumeration, the band widens to .99, and the gate learns to enforce it + +**Status:** RULED 2026-07-27 (operator, GA-R5). Question as presented, verbatim: "R11 -- +VIPs for vault and designate. D-020 already names vault as requiring both a provider and a +metal VIP, so vault is a conformance repair; designate is not in D-020's list and is a new +decision. Octets .61 and .62 are free, and the gate's band cap (.60) must be widened either +way. What shape?" Options presented: (a) both full triples, dual-family, plus the gate fix; +(b) vault metal-only pair per the 2026-07-25 expansion review, designate triple; (c) both +triples with the gate changes deferred to R15. Operator selection, exact utterance: **"Both +full triples (.61 vault, .62 designate), dual-family, and fix the gate (Recommended)"**. + +**VAULT WAS ALREADY RULED, AND NEVER BUILT.** D-020's decision text above enumerates vault +by name among the clustered applications that carry BOTH a provider and a metal VIP. It has +none. Measured: base `vault` is `num_units: 1` with an EMPTY options block. So this half is +a CONFORMANCE REPAIR of a 2026-era decision, not a new choice -- and it is the same class as +the D-134 bands existing only in prose (R4). Two ruled decisions in this audit turned out +never to have been implemented. + +**DESIGNATE IS GENUINELY NEW.** It is absent from D-020's enumeration, which is why it +needed a ruling rather than a repair. This amendment ADDS it. Coherence check that supports +the provider leg: designate's `dnsaas` endpoint is already bound to `provider-public` in the +base bundle, so DNS-as-a-service is tenant-facing by design. + +**RULED SHAPE -- both get the ESTABLISHED triple, not a new form.** Measured octet map, all +eleven existing VIPs are consecutive provider/admin/internal triples: keystone `.50`, +barbican `.51`, cinder `.52`, glance `.53`, magnum `.54`, neutron-api `.55`, +nova-cloud-controller `.56`, octavia `.57`, openstack-dashboard `.58`, placement `.59`, +ceph-radosgw `.60`. The next free octets are `.61` and `.62`: + - **vault -> .61**, **designate -> .62**, each a provider/admin/internal triple in the + per-DC bands, and **DUAL-FAMILY** per the R2 ruling (v4 + v6 from the outset -- adding + v4-only now and re-doing them later would mean re-issuing certificate SANs on a live + cloud, and for vault that is 23 certificate relations). + +**WHY OPTION (b) WAS REFUSED.** The 2026-07-25 expansion review proposed vault as metal-only +with no provider leg, and it has a real technical argument (all 23 vault consumers are +internal). But it CONTRADICTS D-020's own enumeration, so it would have required a D-020 +amendment departing from the decision rather than conforming to it, and it would have made +vault the single non-triple in the bundle -- a permanent special case for +`provider-bundle-check.py`. The conflict is recorded here so the expansion review's proposal +is not later mistaken for the ruled position. + +**BAND WIDENING (mechanical, two files, no choice in it).** `.61` and `.62` are legal under +the D-134 AMENDMENT's `.50-.99` VIP band but are REJECTED by the gate as it stands: +`scripts/provider-bundle-check.py:41` holds `OCTET_LO, OCTET_HI = 50, 60` and +`scripts/lib-net.sh:54-59` holds `VIP_OCTET_MAX=60`. Both widen to `.99` to match D-134. +Note these are SEPARATELY NAMED constants in two files -- raising the band is a two-file +change, not one (audit finding L3-7). + +**GATE HARDENING, ruled IN SCOPE rather than deferred.** `provider-bundle-check.py` is +extended to FAIL on an application that has an `hacluster` relation but no `vip`. Measured +justification: `grep -rn cluster_count scripts/ tests/` returns NOTHING, and a constructed +overlay rewriting all 20 `cluster_count` values from 3 to 1 produces a byte-identical PASS +(audit finding L4-3). That is why decorative HA was found by an audit instead of by a gate. +`VIP_COUNT_EXPECT` also moves 11 -> 13. + +**Execution is a SEPARATE gated step.** Standard delivery discipline applies to the checker +change (harness green, gauntlet, repo-lint, changelog with revert). Per the R6 ruling these +VIPs land BEFORE `overlays/dc-ha-scaleup.yaml` is applied. + ## D-021: Octavia amphora image pipeline on the no-DNS dual-endpoint deploy **Decision:** build the amphora image with the charm-native `octavia-diskimage-retrofit` set `use-internal-endpoints: true`, seeded by a manually uploaded stock Ubuntu base image carrying the five Glance properties the retrofit reads (architecture, os_distro, os_version, version_name, product_name). Park `glance-simplestreams-sync` for the amphora pipeline. The amphora image is `image-format: raw`, tagged `octavia-amphora` to match octavia's `amp-image-tag`.