# Changelog 2026-07-30 (part 3) -- STAGE 5 OPENED: the Juju deployment Session changelog part 3 (part 1 = `changelog-20260730-docfix205-d117-annotation.md`, part 2 = `changelog-20260730-octavia-reissue-tool.md`). Branch `dc-dc-stage5-preconditions`. Status claims live ONLY in `docs/CURRENT-STATE.md`. **Trigger.** The standing operator directive recorded at the 2026-07-30 part-2 close: "we have to continue to juju deployment next session no matter what". This session opens Stage 5 and runs the deployment. **No new D-number (GA-R3).** Opening a stage is OPS; the P5 acceptance is an operational gate disposition against existing SEC rows, not architecture. Next-free UNCHANGED: D 138 / DOCFIX 206 / BUNDLEFIX 053. --- ## Operator rulings recorded (GA-R5, one exchange each, verbatim) 1. **P5 GATE** -- **"Accept and proceed to deploy (Recommended)".** Question as presented and the full consequence text are in `docs/CURRENT-STATE.md` section 1 (the status authority). The six enumerated findings are accepted, known, pre-existing exposure; `preflight.sh` continues to exit FAIL on P5 for the stage's duration and that RED is ruled-accepted. The acceptance covers those six and nothing else. 2. **BOOTSTRAP CONSTRAINT FLAG** -- **"Use both flags".** Question as presented and the full consequence text are in `docs/CURRENT-STATE.md` section 1. The executed bootstrap carries BOTH `--bootstrap-constraints` and `--constraints`. D-104 is NOT amended; only the flag implementing it is clarified. --- ## Items ### 1. Stage 5 OPENED; the P5 acceptance ruling recorded; entry gate captured **What.** `docs/CURRENT-STATE.md` section 1 gains the Stage-5 OPEN entry: the branch decision and why, the measured entry gate, the P5 ruling with the question and the operator's exact utterance, and one logged-not-executed finding. New capture `docs/audit/stage5-preflight-dc0-20260730.txt` (237 lines, `DC=vr1-dc0 bash scripts/preflight.sh` run ON voffice1, exit 1). **Why (evidence).** GA-R1/C1 puts the status change and the document update in one commit; GA-R5 requires the ruling committed and pushed before dependent work. Four read-only checks were made BEFORE putting the question, so it was asked once and asked grounded: - **Both clones at `c58bf95`, same branch, clean.** voffice1 was found on a 105-commit-stale retired branch at the 2026-07-27 close and the "back to `main` at merge" follow-up never fired, because nothing merged. Verified rather than assumed: a stale clone silently deploys the wrong bundle. - **Preflight run ON voffice1, not here.** P5 was found probing the wrong host's filesystem on 2026-07-30 (34 findings vs the true 7), P7 is headend-only, and one gate was found RED on the only host that deploys. A vcloud reading is not the gate reading. - **Deploy artifacts verified as FILES** (`bundle.yaml` VR1 9-node role-separated; both per-DC `-vips`/`-machines`/`-octavia-pki` overlays present, the PKI pair `0600` and gitignored). This is the standing "RULED IS NOT BUILT -- check the artifact" rule applied to the 2026-07-24 committee record, which is now superseded by measurement. - **The deploy-order ruling was READ, not taken from its summary** (`CURRENT-STATE.md:986`). There is no ruled DC ordering; dc1-first artifacts are not a divergence. **Revert.** `git revert ` -- it removes the Stage-5 OPEN entry, the recorded ruling and the capture reference. The capture file itself can be deleted separately; it is evidence, not configuration, and nothing reads it. Reverting the ruling does NOT un-ask the question: re-asking would need a fresh GA-R5 exchange. ### 2. LOGGED, NOT EXECUTED -- `ceph-osd` carries the stale VR0 constraint `tags=openstack` **What.** `bundle.yaml:592`. Recorded in `docs/CURRENT-STATE.md` section 1; no edit made. **Why (evidence).** `ceph-osd` is the ONLY application of 56 carrying a tag constraint -- every other reads `arch=amd64` alone (parsed from `bundle.yaml`, not grepped). The tag is measured ABSENT from the VR1 region: `maas admin tags read` returns `virtual`, `pod-console-logging`, `serial-console`, `openstack-vr1-dc0`, `openstack-vr1-dc1`, `control`, `compute`, `storage`, `juju-controller-vr1-dc0`, `juju-controller-vr1-dc1` -- no bare `openstack`. Neither machines overlay overrides it (`vr1-dc0-machines.yaml` is `applications:`-only and says so). **What is NOT measured, and is labelled as such.** `ceph-osd` has explicit placement (`to: ["5","6","7","8"]`), so the initial deploy is EXPECTED to place by machine id regardless. The reasoned-not-measured exposure is a later unplaced `juju add-unit ceph-osd` matching no machine. The real impact is observable at Step 4.2's `--dry-run` and nowhere earlier, which is why it is recorded now and decided there. Hard rule 1 forbids fixing it mid-step, and the standing rule is that a finding is an observation, not a conclusion. **Revert.** Nothing to revert -- no artifact was changed. ### 3. OWED -- DOCFIX for the Step 2 bootstrap command and D-104's mechanism sentence **What.** Not yet assigned a number (next-free DOCFIX is 206; assign at the point of delivery, per the standing numbering rule -- do not write the token above the high-water mark in prose before it exists). Two surfaces state the bootstrap machine is targeted by `juju bootstrap --constraints tags=juju-controller-$DC`: `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:277-278` and the D-104 amendment's "**Distinct tag, no role tag**" bullet in `docs/design-decisions.md`. **Why (evidence).** Juju 3.6.27's own help, read ON voffice1 rather than from memory, assigns machine-targeting to `--bootstrap-constraints` and model-defaulting to `--constraints` (both sentences quoted verbatim in `docs/CURRENT-STATE.md` section 1). The operator ruled "Use both flags", so the live command is correct; the RUNBOOK is what still reads wrong, and a future DC standup following it literally would get the single-flag form. **No gate reads prose, so nothing in this repo can catch it** -- the same class as the citation defect the 2026-07-27 audit recorded. **Scope note.** The DOCFIX corrects the FLAG only. D-104's decision -- a dedicated per-DC controller VM carrying its own tag and none of the role tags -- is untouched and was independently confirmed live this session: `moved-troll` (`7n87bt`) carries `juju-controller-vr1-dc0` and no `openstack-vr1-dc0`. **Revert.** N/A -- nothing delivered yet; this item is the record that it is owed. ### 4. Bootstrap ATTEMPTED and FAILED; root cause captured; Stage 5 blocked on a ruling **What.** New capture `docs/audit/stage5-bootstrap-reachability-20260730.txt`. Status recorded in `docs/CURRENT-STATE.md` section 1. No reachability change was made. **Why (evidence).** `juju bootstrap` selected the correct machine and MAAS deployed jammy end to end (`Image Deployed -- deployed ubuntu/jammy/amd64/generic`), then juju could not SSH it and released the machine. voffice1 has no route to any DC node plane, and two independent, DELIBERATE controls forbid creating one: SEC-010's transit FORWARD-drop on the rack, and libvirt's blanket reject into the isolated plane bridges. The DC edge has no metal-admin leg. This is a contradiction between ruled surfaces -- SEC-010/D-052 make metal-admin DC-local and forbid the region routing to `10.12.8.0/22`, while D-100 says the fiber carries Juju traffic and D-128 puts the Juju client on voffice1 -- so it needs a ruling, not a firewall edit. **The generalisable lesson, and it is the reason this was invisible for weeks.** SEC-010's cost was assessed with the sentence "a MAAS rack proxies at the application layer and needs no kernel forwarding, so pinning is free." That is true of every Plane-2 tool THEN in use -- MAAS, the inner tofu root over `qemu+ssh`, NetBox -- and false of the one tool that had not been run yet. **A security control priced against the tools you have is not priced against the tools the next stage introduces.** `scripts/site-baseleg.sh:42,47` recorded the same blind spot from the other side, deferring the DC rows because "the DCs nest inside vvr1-dc0 and are reached by qemu+ssh" with a `# MEASURE first` note that was never executed. **Two claim-discipline corrections made to the capture before it was committed**, both worth keeping as examples: (i) the post-failure machine fields (`osystem:""`, `status:Ready/Released`) were first read as "the machine never booted" -- those fields are CLEARED BY THE RELEASE and describe the aftermath, not the attempt; the event log is the authority and it shows a clean full deploy. (ii) The capture initially said the both-flags form "targeted it deterministically"; one run cannot attribute the selection to either flag, only show that A constraint preferred the tagged machine over nine role-tagged candidates. **Revert.** The capture and the CURRENT-STATE entry are records of a live event; reverting them would delete evidence, not undo a change. Nothing was mutated on the cloud by this item. ### 5. D-134 amendment BUILT on both controllers (was ruled-but-not-built) **What.** `vr1-dc0-juju-01` (`7n87bt`, iface 419) and `vr1-dc1-juju-01` (`p8tdwg`, iface 426) converted from a single AUTO v4 link to STATIC dual-stack: `10.12.8.5` + `fd50:840e:74e2:220::5`, and `10.12.68.5` + `fd50:840e:74e2:320::5`. Read back and asserted on content. **Why (evidence).** Operator ruling 2026-07-30, exact utterance **"Fix now: static .5 + v6, re-bootstrap (Recommended)"**. Both controllers held AUTO, v4-only addresses while all nine role nodes per DC hold STATIC dual-stacked addresses in their D-134 bands -- the controller VMs were added on 2026-07-29, after both the D-134 carve and the IPv6 carve, so neither reached them. The D-134 amendment of 2026-07-29 ruled `.5` "on every plane it is attached to" and made the octet map a STANDING cross-DC standard; it was ruled-but-not-built until this item, the same class the 2026-07-27 audit found twice. **AUTO was the live hazard, not the octet.** An auto address is not pinned: a future redeploy of the controller machine could return a different address, and the controller address is written into every unit's `agent.conf`, so every agent in the cloud would lose its controller at once. **Values were derived, not typed.** The v6 prefixes were confirmed by VLAN pairing -- dc0 v4 subnet 6 and v6 subnet 21 are both `vlan 5005/fabric-4`; dc1 v4 subnet 11 and v6 subnet 27 are both `vlan 5143/fabric-142` -- combined with the 2026-07-27 ruling that the v6 host part mirrors the v4 octet. Inferring the prefix from a single node's address would have been the hard-rule-2 violation. **Revert.** Per controller: `maas admin interface unlink-subnet id=` for each of the two new links, then `maas admin interface link-subnet mode=AUTO subnet=` to restore the original single auto link. dc0 = `7n87bt` iface `419` subnet `6`; dc1 = `p8tdwg` iface `426` subnet `11`. Both machines are `Ready` and powered off, so this is safe at any time before they are allocated.