diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 936f9c8..42d63ef 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1766,13 +1766,39 @@ a map REPLACE, and the dry-run cannot see options at all. Both overlays' VERIFY-LIVE headers, which instructed the reader to assert this AT the dry-run, are corrected in place and now point at 4.4. - **CONTRADICTION MEASURED, LOGGED NOT RESOLVED (hard rule 1):** the phase-4 runbook says - `bundle.yaml` ships "NO designate" for this stage (D-019 as superseded by D-106), while - the plan deploys `designate`, `designate-bind`, `designate-hacluster` and - `designate-mysql-router` and places `designate/0` on `0/lxd/5`. One of the two is wrong; - it is not resolvable from the runbook and is NOT deploy-blocking (designate deploying - early costs containers, not correctness). Annotated at the bullet so no session reads it - as a fact about the current bundle. + **>>> A "CONTRADICTION" I RAISED HERE WAS NOT ONE, AND THE OPERATOR CAUGHT IT AS A + GROUNDING FAILURE. WITHDRAWN IN FULL. <<<** I recorded that the plan deploying four + designate applications contradicted the phase-4 bullet saying `bundle.yaml` ships "NO + designate", and put it up as an unresolved question. **There was nothing to resolve.** + D-019 (v1 ships no cloud DNS) is SUPERSEDED by **D-106, which REACTIVATES Designate for + VR1** -- Designate is one of THIS generation's ADDED services. DOCFIX-167 put all four + designate applications INTO the `bundle.yaml` this stage deploys on 2026-07-10, and + `runbooks/phase-01-bundle-deploy.md:13-16` and `:174` already SAY SO, the latter in as + many words: it "corrects this GATE's old 'NO designate (D-019)' text, since D-019 is + superseded". `bundle.yaml:898-902` and `docs/dc-dc-deployment-workflow.md` Stage 7 both + scope Stage 7 to the DNS ACTIVATION -- per-DC zones, A/AAAA per the D-008 bootstrap + order, the FQDN-SAN certs closing the D-019/D-021 root cause, the coupled B5 + `os-public-hostname` reversal -- explicitly NOT the charm deploy. **So four designate + applications in the Stage-5 plan is the planned, correct outcome; their ABSENCE would + have been the defect.** The only stale artifact was the phase-4 bullet, which paraphrased + a gate text phase-01 had already corrected 23 days earlier; it is now rewritten to state + the D-106 reactivation and the Stage-5/Stage-7 split, and my annotation is deleted rather + than left as history because it would mislead the next reader on a live deploy input. + **OPERATOR CORRECTION, 2026-08-02, and the reason this is recorded rather than quietly + fixed:** *"you have completely missed the shape, grounding, and goal of this version of + the deployment. We have been building on each previous successful deployment and layering + on new services and features in a deliberate and planned manner ... In the past that has + caused huge problems with next step attention and you have gotten stuck troubleshooting + and diagnosing rather than working through steps to continue the deployment."** The + standing lesson this repo already carries -- a finding is an observation, not a + conclusion; MEASURE before putting it to the operator -- covers exactly this: two greps + (D-106's Status line, phase-01:174) would have withdrawn it before it was ever raised. + **VR0 -> VR1 is ADDITIVE. Before flagging any application in the plan as unexpected, + check whether a D-number ADDS it in this generation** -- Designate (D-106), cinder-backup + and ceph-rbd-mirror (D-108) are all VR1 additions carried in the same shared bundle. + **RELATED, and expected for the same reason:** the dry-run's `WARNING These fields ... + line 62: field name ... line 96: field variables ... will be ignored` is the pair of + benign R11 warnings `phase-01-bundle-deploy.md:175-176` already documents. Not a finding. **THE DEPLOY ITSELF IS NOT RUN.** Step 4.3 is a gated MUTATION and awaits operator approval; the dry-run is where this session stops. diff --git a/docs/changelog-20260802-deploy-input.md b/docs/changelog-20260802-deploy-input.md index 63f5d8f..83da045 100644 --- a/docs/changelog-20260802-deploy-input.md +++ b/docs/changelog-20260802-deploy-input.md @@ -184,15 +184,53 @@ with the vips overlay ONLY, so it grades a narrower input than either preflight P2 or the deploy command. Not deploy-blocking (teardown-time check), DOCFIX material for the same fold. -2. **The runbook says `bundle.yaml` ships "NO designate" for this stage; the plan - deploys four designate applications** and places `designate/0` on `0/lxd/5`. - One of the two is wrong and it is not resolvable from the runbook. NOT - deploy-blocking -- designate deploying early costs containers, not correctness. - The bullet is annotated in place so no session reads it as a fact about the - current bundle; the underlying question (does D-106 leave designate in the - Stage-5 bundle?) is unanswered and left for the operator. +Recorded in `docs/CURRENT-STATE.md`, not actioned. -Both recorded in `docs/CURRENT-STATE.md`, neither actioned. +## Item 4b -- WITHDRAWN: the designate "contradiction" was a grounding failure of mine + +I raised, as an unresolved question for the operator, that the plan deploys four +designate applications while the phase-4 bullet says the bundle ships "NO +designate". **There was nothing to resolve, and two greps would have shown it.** + +- **D-019 is SUPERSEDED by D-106**, which REACTIVATES Designate for VR1. Designate + is one of this generation's ADDED services. +- **DOCFIX-167 put all four designate applications into this `bundle.yaml` on + 2026-07-10**, and `runbooks/phase-01-bundle-deploy.md:13-16` / `:174` already + record it -- `:174` says the change "corrects this GATE's old 'NO designate + (D-019)' text, since D-019 is superseded". +- **Stage 7 owns the DNS ACTIVATION, not the charm deploy**: per-DC zones + A/AAAA + per the D-008 bootstrap order, FQDN-SAN certs closing the D-019/D-021 root cause, + the coupled B5 `os-public-hostname` reversal (`docs/dc-dc-deployment-workflow.md` + Stage 7; `bundle.yaml:898-902` says the same). + +Four designate applications in the Stage-5 plan is the PLANNED outcome; their +absence would have been the defect. The stale artifact was the phase-4 bullet +alone, paraphrasing a gate text phase-01 corrected 23 days earlier. It is rewritten +to state the D-106 reactivation and the Stage-5/Stage-7 split; my annotation is +DELETED rather than kept as history, because leaving it would mislead the next +reader about a live deploy input. + +**OPERATOR CORRECTION, quoted because the failure is the point:** *"you have +completely missed the shape, grounding, and goal of this version of the deployment. +We have been building on each previous successful deployment and layering on new +services and features in a deliberate and planned manner ... In the past that has +caused huge problems with next step attention and you have gotten stuck +troubleshooting and diagnosing rather than working through steps to continue the +deployment."* + +**The durable rule: VR0 -> VR1 is ADDITIVE.** Before flagging any application in a +plan as unexpected, check whether a D-number ADDS it in this generation -- Designate +(D-106), cinder-backup and ceph-rbd-mirror (D-108) all arrive that way in the same +shared bundle. This repo's standing lesson already covers the process failure: a +finding is an observation, not a conclusion -- measure before putting it to the +operator. + +**Same class, also withdrawn:** the dry-run's `WARNING These fields ... name ... +variables ... will be ignored` is the pair of benign R11 warnings +`phase-01-bundle-deploy.md:175-176` already documents. I had not flagged it, but I +had not recognised it either. + +- **Revert:** n/a -- this item removes a defect I introduced. ## Item 5 -- the instrument finding GRADUATES out of the changelog diff --git a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md index ea6d522..c25fac3 100644 --- a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md +++ b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md @@ -688,18 +688,26 @@ Open the Step 4b watch windows before this returns. -- **CONTRADICTION MEASURED 2026-08-02, LOGGED NOT RESOLVED (hard rule 1).** The - bullet below says `bundle.yaml` ships "NO designate". The dc0 dry-run plan - deploys `designate`, `designate-bind`, `designate-hacluster` and - `designate-mysql-router`, and places `designate/0` on `0/lxd/5` - (`docs/audit/stage5-dryrun-dc0-20260802.txt`). One of the two is wrong and it - is not resolvable from this runbook: either the bullet is stale prose, or the - bundle carries applications this stage is not meant to deploy. It is NOT - deploy-blocking either way -- designate deploying early costs containers, not - correctness -- but do not read the bullet as a fact about the current bundle. -- `bundle.yaml` ships "NO designate" for THIS stage per phase-01's own gate text - (D-019, as superseded by D-106): Designate reactivation is Stage 7's job, do - not reactivate it mid-Stage-5. +- **DESIGNATE DEPLOYS HERE, AND THAT IS CORRECT. CORRECTED 2026-08-02 (DOCFIX-208).** + This bullet used to read `bundle.yaml` ships "NO designate" for this stage. That + was VR0's posture and it has been wrong since 2026-07-10. **D-019 (v1 ships no + cloud DNS) is SUPERSEDED by D-106, which REACTIVATES Designate for VR1** -- + Designate is one of this generation's ADDED services, not a deferred one, and + the VR1 buildout layers new services onto each previous successful deployment + by design. DOCFIX-167 put `designate`, `designate-bind`, `designate-mysql-router` + and `designate-hacluster` INTO the `bundle.yaml` this stage deploys; + `runbooks/phase-01-bundle-deploy.md:13-16` and `:174` already record that and + say explicitly it "corrects this GATE's old 'NO designate (D-019)' text". + Confirmed live: the dc0 dry-run deploys all four and places `designate/0` on + `0/lxd/5` (`docs/audit/stage5-dryrun-dc0-20260802.txt`). **EXPECT THEM IN THE + PLAN; their absence would be the defect.** +- **What IS Stage 7's job is the DNS ACTIVATION, not the charm deploy** -- per-DC + zones with A/AAAA per the D-008 bootstrap order, the FQDN-SAN certs that close + the D-019/D-021 root cause, and the coupled B5 `os-public-hostname` reversal + (`docs/dc-dc-deployment-workflow.md` Stage 7; `bundle.yaml:898-902` says the + same: "the zone name/A/AAAA population itself is NOT part of this bundle"). + Do not perform that activation mid-Stage-5; do not read it as a reason to keep + the charms out. - Settle to phase-01's documented PRE-vault-init end state, read with `$DC_MODEL` substituted for its hardcoded model name: ZERO units in `error`; mysql-innodb-cluster ACTIVE; `vault/0` BLOCKED "Vault needs to be initialized" @@ -743,11 +751,9 @@ > against a measured instrument -- `juju config` is what holds the merged > configuration -- but it has never run, because the model was empty when the > gate was written. Its FIRST execution is at this deploy. Expect to correct its -> shape, not its intent; report a correction rather than working around it. Note -> in particular that `designate` appears in the loop while a logged, unresolved -> contradiction says the bundle should not carry designate at this stage -- if -> that resolves the other way, drop it from the list rather than reading the -> sentinel as a fault. +> shape, not its intent; report a correction rather than working around it. +> `designate` belongs in the loop: D-106 reactivates it for VR1 and the charm +> deploys at this stage (see Step 4.3's note). **GATE:** 1. **`ovn-chassis` carries all THREE options.** `bridge-interface-mappings`