diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index acd99ca..a6d32de 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -555,6 +555,24 @@ equivalent scheme.** The v6 pass is FORCED to follow the R2 carve (a range cannot be reserved on a subnet that does not exist), not deferred by choice. Execution is a separate gated step. + **R5 RULED 2026-07-27 -- exact utterance "Accept at Stage 5; rewrite Stage 7 Step 5 to + configure-not-deploy (Recommended)"**, recorded as a **D-106 RULING NOTE (2026-07-27)**, + amending nothing in D-106's bootstrap order. Measured before presenting: all four + designate apps and all EIGHT relations are DEPLOY-READY at Stage 5 (every peer is created + by Stage 5), but will be FUNCTIONALLY INERT -- `os-public-hostname` is set in NO deploy + artifact (`bundle.yaml:11` records the current posture as IP-ONLY, "the dual VIPs ARE the + catalog endpoint"). So designate lands as inert infrastructure at Stage 5 and Stage 7 + retains the substantive D-106 work it always owned. **CORRECTION RECORDED IN THE DECISION: + the audit first told the operator this option "inverts D-106's bootstrap order" -- it does + NOT. D-106's order is a CONFIGURATION sequence (hostname -> FQDN-SAN certs -> zones -> + neutron) governing when the DNS wiring happens, not when the charm is installed.** + **NEW SURFACE DEFECT: `runbooks/dc-dc-phase6-designate-cos-magnum.md` contradicts itself** + -- `:172` says no designate application block exists anywhere, `:178` says designate is + deployed in-bundle; the bundle settles it (DOCFIX-167, 2026-07-10) and the runbook needs + rewriting regardless. Option (c), setting `os-public-hostname` at Stage 5, was refused as + the one branch that genuinely collides with D-106 -- it recreates the D-019 root cause + (metal-only charms pulling a public FQDN endpoint they cannot resolve) before the FQDN-SAN + certs exist. Remaining: R6-R11 blocking, R12-R15 standing. - 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 d51a85c..3301123 100644 --- a/docs/audit/queued-rulings-20260727.md +++ b/docs/audit/queued-rulings-20260727.md @@ -266,11 +266,27 @@ - **(a)** Suppress Designate for the Stage-5 deploy (a subtractive overlay, or a rendered per-stage bundle) and keep Stage 7's incremental-add shape intact. - **(b)** Accept Designate landing at Stage 5 and rewrite Stage 7 Steps 1/5 into a - "configure, not deploy" shape. **Caveat worth weighing:** D-106's own bootstrap + "configure, not deploy" shape. ~~**Caveat worth weighing:** D-106's own bootstrap order puts `os-public-hostname` + FQDN-SAN certificates BEFORE Designate; - option (b) inverts that order. + option (b) inverts that order.~~ **THIS CAVEAT WAS WRONG AND IS STRUCK.** D-106's + order is a CONFIGURATION sequence (hostname -> certs -> zones -> neutron); it governs + when the DNS wiring happens, not when the charm is installed. Deploying the app + earlier does not invert it -- the zones still follow the certs. See the correction + recorded in the D-106 RULING NOTE 2026-07-27. -OPERATOR UTTERANCE: +OPERATOR UTTERANCE: **"Accept at Stage 5; rewrite Stage 7 Step 5 to configure-not-deploy +(Recommended)"** -- RULED 2026-07-27. **R5 IS CLOSED.** Recorded as a **D-106 RULING NOTE +(2026-07-27)**, amending nothing in D-106's order. Measured before presenting: all four +designate apps and all EIGHT relations are deploy-ready at Stage 5 (every peer -- +mysql-innodb-cluster, keystone, rabbitmq-server, vault, memcached, designate-bind -- is +created by Stage 5), but they will be FUNCTIONALLY INERT because `os-public-hostname` is +set in no deploy artifact. **New surface defect found: `dc-dc-phase6-designate-cos-magnum.md` +CONTRADICTS ITSELF** -- `:172` says no designate application block exists anywhere, +`:178` says designate is deployed in-bundle. The bundle settles it (DOCFIX-167, 2026-07-10), +and the runbook needs rewriting regardless of this ruling. Option (c) -- setting +`os-public-hostname` at Stage 5 -- was refused as the one branch that genuinely DOES +collide with D-106: it recreates the D-019 root cause (metal-only charms pulling a public +FQDN endpoint they cannot resolve) before FQDN-SAN certs exist. --- diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 07e6310..31c4d33 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2359,6 +2359,78 @@ --- +### D-106 RULING NOTE 2026-07-27 -- Designate DEPLOYS at Stage 5 and is CONFIGURED at Stage 7; Stage 7 Step 5 stops being a deploy step + +**Status:** RULED 2026-07-27 (operator, GA-R5). This note records a ruling and AMENDS +NOTHING in D-106's bootstrap order, which stands exactly as written. + +Question as presented, verbatim: "R5 -- Designate. The four apps and eight relations are +deploy-ready at Stage 5 and will deploy from the bundle, but sit inert because +os-public-hostname is set nowhere. Stage 7's Step 5 is written as a DEPLOY step with a gate +requiring the diff show only new designate apps -- and phase-6 contradicts itself internally +(line 172 says no designate block exists, line 178 says it is deployed in-bundle). How +should this resolve?" Options presented: (a) accept at Stage 5 and rewrite Stage 7 Step 5 to +configure-not-deploy; (b) suppress designate at Stage 5 to preserve the incremental-add +shape; (c) accept at Stage 5 AND set `os-public-hostname` there. Operator selection, exact +utterance: **"Accept at Stage 5; rewrite Stage 7 Step 5 to configure-not-deploy +(Recommended)"**. + +**CORRECTION RECORDED IN THE DECISION ITSELF.** When this question was first put to the +operator, the audit stated that option (a) "inverts D-106's bootstrap order, which puts +`os-public-hostname` + FQDN-SAN certs BEFORE Designate". **That was wrong.** D-106's order +(`static /etc/hosts -> os-public-hostname per API charm -> Vault issues FQDN-SAN certs -> +Designate zone plus A/AAAA -> Neutron default_dns_domain and dns_servers -> tenant subnets +with --dns-nameserver`) is a CONFIGURATION sequence. It governs when the zones and DNS +wiring happen, NOT when the charm is installed. Deploying the designate application earlier +does not violate it: the zones still come after the certs. Installing a charm and doing +D-106's work are different things, and conflating them nearly cost the operator a decision +made on a false constraint. + +**MEASURED STATE (2026-07-27).** The bundle carries four applications -- `designate` +(`2024.1/stable`, `num_units: 1`, `to: [lxd:0]`), `designate-bind` (`2024.1/stable`, +`to: [lxd:2]`), `designate-mysql-router` (`8.0/stable`) and `designate-hacluster` +(`2.4/stable`, `cluster_count: 1`) -- plus EIGHT relations, all of whose peers Stage 5 +creates: `mysql-innodb-cluster`, `keystone`, `rabbitmq-server`, `vault`, `memcached` and +`designate-bind` itself. They are therefore DEPLOY-READY at Stage 5 and will deploy. +They will also be FUNCTIONALLY INERT: `os-public-hostname` is set in NO deploy artifact -- +`bundle.yaml:11` records the current posture as "IP-ONLY -- os-public-hostname dropped on +all API charms; the dual VIPs ARE the catalog endpoint". So the charm runs and the feature +does not, which is precisely the state Stage 7 exists to resolve. + +**THE SURFACE DEFECT: `runbooks/dc-dc-phase6-designate-cos-magnum.md` CONTRADICTS ITSELF.** +`:172` states "There is no `designate:` or `designate-bind:` application block anywhere in +..." while `:178` states "Designate is deployed in-bundle in each DC, backend +`designate-bind`". Both cannot be true; the bundle settles it, and DOCFIX-167 put designate +there on 2026-07-10. Step 5 (`:351`) is written as "Deploy designate + designate-bind into +the LIVE per-DC model" with a gate (`:366-367`) requiring "the diff shows ONLY the new +designate/... applications and their relations being added" -- unsatisfiable against a model +that already has them. The runbook already knows where the real work is: `:210` calls it a +"larger surface than 'add designate': every API charm's `os-public-hostname`". + +**RULED SHAPE.** Designate lands as INERT INFRASTRUCTURE at Stage 5. Stage 7 retains the +substantive D-106 work it always owned -- `os-public-hostname` on every API charm, Vault +FQDN-SAN certs, the zone plus A/AAAA records, Neutron `default_dns_domain`/`dns_servers`, +and tenant subnets with `--dns-nameserver` -- and Step 5 is rewritten from "deploy" to +"verify present and active, then configure". Its diff-gate is replaced by a presence-and- +state assertion. Step 1's inventory prose (`:172`) is corrected to match `:178` and the +bundle. The rewrite is owed regardless of this ruling, because the runbook is internally +inconsistent today. + +**Why (b) was refused:** suppressing designate at Stage 5 needs machinery that does not +exist (a subtractive overlay or a rendered per-stage bundle) and partially undoes +DOCFIX-167, a deliberate decision. It would build a mechanism to satisfy a stale gate +rather than fix the gate. + +**Why (c) was refused, and this one matters:** setting `os-public-hostname` at Stage 5 is +the ONE option that genuinely collides with D-106. Publishing a public FQDN endpoint before +Vault has issued FQDN-SAN certs recreates the exact D-019 root cause D-106 was written to +remove -- metal-only charms pulling a public FQDN endpoint they cannot resolve, which is +also the D-021 amphora-pipeline constraint. It would need its own ruling on cert sequencing +and was not taken. + +**Execution:** a DOCFIX against the phase-6 runbook (Step 1 inventory prose, Step 5 verb and +gate). Logged to the Stage-5 audit's Phase-3 batch; not executed under this ruling. + ## D-107: Airgap posture, per-DC artifact mirror, and NTP (VR1) **Status:** ADOPTED 2026-07-09 (operator ruling).