# Roosevelt / future-deployment HELD-decisions review -- reevaluated against current project state **ANALYSIS + RECOMMENDATION PACKAGE, NOT A RULING.** Mutates no authoritative surface. Every "pull forward" is a candidate for a gated operator exchange (GA-R5 to un-defer a ruling; presented-and-approved to change implementation timing). Companion to `docs/audit/open-items-review-20260809.md`. - Author: this session, 2026-08-09. Read-only. - Inventory source: an exhaustive sweep of `docs/design-decisions.md` (every D-block + amendment) for decisions/sub-decisions whose RULING or IMPLEMENTATION is held to Roosevelt / "the next deployment" / end-of-deployment review. Full raw enumeration is reproduced in Section 5. --- ## 0. The evaluative frame -- what changed, and the one disambiguation that governs it all The operator's premise: enough has changed to reevaluate what is still correctly held for the future. The material changes since these deferrals were set: 1. **The re-IP redeploy on `10.13.0.0/16` (D-143, ruled today) is a near-term SECOND full build.** dc0 finishes as a checkpoint, then the substrate is torn down and redeployed. 2. **geneve-over-v6 is LIVE-CONFIRMED working** (D-139 amendment) -- v6-only east-west is viable. 3. **The deploy method is now proven** -- dc0 is a live 66-machine / 162-unit cloud. 4. **The tailnet-collision incident** -- the shared, unpoliced, allow-all Headscale is what caused the entire re-IP pivot. That converted a *theoretical* isolation exposure into a *demonstrated* one. 5. **Precedent: Roosevelt items get pulled forward when the need arises** -- D-132 q1 (per-DC MAAS region) and D-138 (client-in-DC) were both pulled forward from Roosevelt into VR1. **>>> THE DISAMBIGUATION THAT PREVENTS THE OBVIOUS ERROR. <<<** In these decisions, **"next deployment" means Roosevelt -- the next DISTINCT, bare-metal build with real hardware specs -- NOT the intra-VR1 re-IP redeploy.** The 10.13 redeploy is a re-build of the *same* VR1 rehearsal on the *same* nested VMs; it has no real switch/NIC inventory, no IPMI/BMC, no bare-metal capacity. So it CANNOT exercise anything hardware- or scale-bound (bonds/trunks, NIC budgets, HA at scale, hardware edge plugins). Treating the redeploy as "the next deployment" would wrongly pull those forward. **But the redeploy IS a fresh-build opportunity for anything that (a) is exercised at ANY full build and (b) does not need bare metal:** the credential lifecycle, the Vault init, the v6 re-carve. Those are the genuine pull-forwards. The recommendation groups below split exactly on that line. ### 0.1 UPDATE 2026-08-09 -- operator preview of TWO material near-term changes (reframes the horizon) When asked whether hardware specs exist (the discriminating question for Group 4), the operator answered **"Not yet"** -- so **Group 4 stands as written for THIS redeploy** (still generic nested VMs). But the answer previewed two structural changes that reframe the review: 1. **The dc0/dc1 CONTAINER LAYER is being ELIMINATED in this rebuild.** Operator: the nested containment layer "will not provide the testing environment I was assuming ... has only caused more trouble than beneficial data ... pull all deeper layers up one and simplify the wiring." This is an **[ARCH] substrate change** to the D-122/D-123 Model-B nested containment -- it changes the re-IP (D-143) EXECUTION topology, not just the addresses. **OWED (flagged, not designed here):** it warrants its own decision/amendment at redeploy planning (a D-123 amendment or new D-number -- architectural consequence + Roosevelt-delta, GA-R3). Captured so it is not lost; the design is the next planning session's, with the operator's topology detail. 2. **A PRE-ROOSEVELT BARE-METAL TEST is imminent** -- "a smaller set of hardware ... specs within a few days so we can plan deployment ... a good test of the module deployment project we are developing during the teardown and redeploy." **This COMPRESSES the Group-4 horizon:** the "next distinct deployment" is no longer far-future Roosevelt but a near-term bare-metal test. The Group-4 bare-metal/hardware items (D-133 part-2, D-059, D-100, D-129 metal-edge profile, D-104 HA, D-052 planes) keep their deferral (specs not here yet) but their REVIEW POINT is now weeks away, not "someday." Re-run this Group-4 assessment against the real hardware sheets when they arrive -- several may move to pull-forwards for the bare-metal test. Net: this redeploy's yield is unchanged (Group 4 stands, no specs), but the container-layer elimination is a new owed [ARCH] item for the redeploy plan, and the bare-metal test makes a Group-4 re-run imminent rather than distant. --- ## 1. GROUP 1 -- PULL FORWARD to the 10.13 redeploy (fresh-build items, not bare-metal-bound) These retire naturally at the redeploy because the redeploy re-runs the exact build step they govern. No new ruling needed for most -- this is implementation timing. - **D-137 -- "real credential hardening (rotation, revocation, non-shared tokens)" deferred to post-teardown cycles.** The re-IP TEARDOWN *is* the post-teardown cycle D-137 named. This is the same finding as open-items-review **R7** (the teardown runbook has no credential-revocation checklist). **Recommendation:** build the revocation step into the teardown, so the redeploy re-mints on a clean slate. Actionable now (build R7). **Precision (advisor-flagged):** the teardown discharges only the REVOCATION leg for the DC-substrate material (Section 3b); the ROTATION leg for the persistent-host credentials (Section 3a -- Office1/vcloud-resident) still lands at v1 close. D-137 is not fully discharged by the redeploy. - **D-142 -- vault-init QoL sweep, "implement + test on the next opportunity."** The next opportunity is literally the redeploy's Vault standup. Same as open-items-review **R6**. **Recommendation:** fix R1's `-m` model-target DEFECT before the next Vault init, put R2's off-host transport question to the operator, build + test the QoL there. - **D-136 (octet-convention half only) -- "IPv6 host-part octet convention: review at the end of the project."** The re-IP re-carves the entire VR1 v6 apex under the new B2 role. That re-carve is the natural, cheaper moment to settle the octet convention than a separate end-of-project pass. **Recommendation:** fold the octet-convention review into the D-143 B2 v6 re-carve. NOTE: D-136's *other* held half -- the automation/CI placement (F2/F3, the Jenkins job on per-DC utility-node agents) -- does NOT move; it is coupled to D-132 and is in Group 4. - **D-069 / SEC-003 -- unseal-key custodian ASSIGNMENT (+ second-person unseal rehearsal).** This is *operator input*, not a hardware/scale blocker -- decidable any time, and the redeploy re-inits Vault, which is the natural rehearsal window for a second-person unseal. **COUNTERWEIGHT (state it, do not gloss):** this is a STANDING operator choice, not an oversight -- SEC-003 was operator-DEFERRED 2026-07-06 and reaffirmed, and its own row records that the deferral "keeps d011-06 MANUAL, gates D-011 full close" (bus-factor open since 2026-07-03). **Recommendation:** SURFACE it for reconsideration at the redeploy Vault init -- the re-init is a rare low-cost window to assign custodians and rehearse, and D-011's full close depends on it -- but it is the operator's standing call to un-defer (a GA-R5 ruling). NOTE: D-069's *other* held item, auto-unseal (transit/cloud KMS), is a SEPARATE future decision and is NOT decidable here -- it is in Group 4 (version-bound, D-068-coupled). ## 2. GROUP 2 -- PULL FORWARD the ANALYSIS/PREP only (the RULING stays future) Research is cheap; these are reviews that can be *conducted* now without the future deployment, feeding a future ruling. Doing them now de-risks the eventual ruling. - **D-131 sub-4 -- the PINNED node-DNS architectural review** (best-practice conformance; security of the metal-admin forwarder; vendor-documented utility-node DC-to-DC config). dc0's forwarder is live and proven, so the review has a real subject NOW. **Recommendation:** conduct the (a)/(b)/(c) review this deployment; the sub-4 *ruling* stays Roosevelt (still gated on the upstream MAAS-agent-resolver LP outcome). - **D-140 -- OpenTofu-manages-Juju, the owed "provider capabilities must be READ, not recalled."** The ruling stays at end-of-deployment (and per its sequencing lands *after* the 10.13 redeploy, since the "hardened + tested" deployment is the redeployed one). But the precondition it named (a proven deploy method) is now largely met, and the provider-capability read is prep that can be done anytime. **Recommendation:** do the `references/opentofu-provider-docs.md` provider-capability read now so the end-of-deployment ruling is ready; keep the ruling itself deferred. - **D-068 item 1 -- the V1-V5 migration re-verify probes** (the ruling requires them RE-RUN at Roosevelt, "not cited stale"; last run 2026-07-23). **Recommendation:** re-baseline the probes opportunistically (they inform the D-071 monthly review too); the Q2 PATH ruling (2a/2b/2c) genuinely stays Roosevelt Vault design time. ## 3. GROUP 3 -- RECONSIDER given a specific project change (surface for operator decision) - **D-129(iii) -- TAGGED identity + autoApprovers + the STAR ACL, "deferred to bare-metal" (operator, 2026-08-07: "We can pin those for the bare metal install").** This is the one the collision incident directly bears on. **The exposure D-129(iii)(b) describes -- "an unpoliced Headscale is allow-all" with no enforced DC-isolation boundary -- is exactly the class of failure that produced the 10.12/10.13 collision.** The re-IP re-stands the `.7` routers on 10.13, which is the natural moment to bring them up TAGGED with the star ACL, and doing so would also retire the note-1 key-expiry outage risk the untagged nodes carry. **HONEST COUNTERWEIGHT:** the deferral has a HARD blocker that has not changed -- the Headscale control plane is Cloudflare-fronted and **the operator has no access to it** (note 4, measured). Without that access the tagged/ACL work cannot be built regardless of the risk calculus. **Recommendation:** SURFACED for reconsideration -- the collision moved this from theoretical to demonstrated, so it is worth pulling forward to the redeploy *iff* Headscale control-plane access is obtainable. If access stays blocked, it correctly remains deferred, and the star boundary stays a KNOWN, accepted VR1 exposure (as D-129(iii)(b) already records). ## 4. GROUP 4 -- STAYS FUTURE, correctly held (bare-metal / scale-bound; redeploy is nested VMs) Each of these needs real hardware, real scale, or an external spec the redeploy does not supply. The reevaluation CONFIRMS the deferral. No action. | Decision | What is held | Why it genuinely stays | |---|---|---| | **D-052(a)/(b)** | dedicated corosync heartbeat ring; dedicated live-migration plane + QEMU-native TLS | need dedicated planes/hardware; hardening, not blocking (QEMU-TLS is VM-testable if ever wanted, low value) | | **D-059** | four-NIC collapse | gated on Roosevelt hardware sheets (NIC budget) | | **D-100** | netem inter-DC link profile | awaiting the external Roosevelt link spec | | **D-104** | 3-unit Juju controller HA | "when bare-metal resources allow"; VR1 VM capacity is ~85% FIT | | **D-108** | rbd-mirror daemon HA | Roosevelt scale-up | | **D-121** | Vault HA backend Raft-vs-etcd | Raft is a 1.16-charm feature, incompatible now; coupled to the D-068 vault-version path | | **D-129 os-frr** | dynamic routing at the edge | Roosevelt inter-DC design (needs the D-100 link spec + D-132 topology) | | **D-129 metal-edge profile** | os-smart / os-nut / os-cpu-microcode / os-lldpd | hardware-specific (SMART disks, UPS, CPU microcode) -- inert on VMs | | **D-129 security hardening** | Suricata / crowdsec / Zenarmor / SIEM | deferred by the closed-test posture to post-teardown/Roosevelt | | **D-129(iii)(c)/(d)** | two-router Tailscale HA; per-operator source-IP preservation | HA scale-up class (D-121-coupled) | | **D-132 Q1/Q2/Q3** | HA-region sub-questions; rack-top rack controllers; cross-site backup custody | multi-rack / HA / cross-site scale -- the redeploy has one rack per DC | | **D-133 part 2** | hardware-faithful NIC topology (bonds/trunks) | needs real switch/NIC inventory; the redeploy is still 6-flat-NIC VMs | | **D-139 VPN (:e0); external v6 routing** | operator-access VPN; external v6 transit | Roosevelt edge design; the VR1 edge has no v6 transport | | **D-029** | Keystone SSO (`k8s-keystone-auth`) for workload clusters | can't be exercised -- Magnum/CAPI is deferred to the redeploy (no workload clusters to run SSO on), and D-029's dependency is the Roosevelt cloud-internal-DNS + trusted-cert foundation. D-106's Designate reactivation is a *partial* move toward that foundation but does NOT discharge D-029 | | **D-068 item 2 (listener TLS)** | Vault listener-TLS at the region | a "Roosevelt build requirement -- lands at Roosevelt Vault standup with its own runbook step"; VR1 stays cleartext by ruling | | **D-068 item 3 (AppRole lifecycle)** | TTL audit, renewable/auto-renew TTLs, per-consumer auth probe | "all three legs are Roosevelt build requirements" (the per-consumer probe already ships into `cloud-assert.sh` for VR1; the rest is Roosevelt) | | **D-069 auto-unseal** | evaluate transit/cloud-KMS auto-unseal | a SEPARATE future decision, and version-bound -- transit/KMS auto-unseal capability tracks the Vault version the D-068 item-1 Q2 path hasn't ruled, so the redeploy cannot settle it | | **D-136 automation/CI half** | F2/F3 (CI runner / event delivery / status-back); Jenkins job placement | "the Roosevelt shape once D-132 ratifies" -- gated on D-132 (which itself stays, Group 4) | ## 5. GROUP 5 -- RECORD HYGIENE (defers that project state has already superseded/moved) - **D-019 (Designate deferred to v2/Roosevelt) is SUPERSEDED FOR VR1 by D-106** -- Designate DEPLOYS at Stage 5 in VR1 (the checkpoint's owed "test zone" is exactly this). The VR0/v1 record holds, but the "held for Roosevelt" framing is stale for the current mission. **Recommendation:** no action needed (D-106 already governs); noted so it is not mistaken for a live hold. - **D-042 is DISCHARGED, not held** -- the released-tag driver pin (`magnum-capi-helm==1.4.0`) shipped the capability; the interim dev-commit path is retired. Listed only to close the loop. - **D-010 NetBox merge-back to `netbox.baldurkeep.com` ("a maybe" at end-of-deployment)** -- the re-IP re-carves the working apex on 10.13 under the new B2 role, which changes *what* would merge back. **Recommendation:** revisit the merge-back plan when the re-IP re-carve is done; still a "maybe," now with a different payload. --- ## 6. Prioritized recommendation summary | # | Decision(s) | Recommendation | When | |---|---|---|---| | 1 | **D-137 / R7** | Build the teardown credential-revocation checklist | at the re-IP teardown | | 2 | **D-142 / R6** | Fix the `-m` model defect; build+test the vault-init QoL; put R2 to operator | before the 10.13 Vault init | | 3 | **D-136** | Fold the IPv6 octet-convention review into the B2 v6 re-carve | with the D-143 re-carve | | 4 | **D-069 / SEC-003** | Decide unseal custodians + rehearse second-person unseal (needs a ruling to un-defer) | at the redeploy Vault init | | 5 | **D-131 sub-4** | Conduct the pinned node-DNS architectural review now (ruling stays Roosevelt) | this deployment | | 6 | **D-140** | Do the provider-capability READ now (ruling stays end-of-deployment) | anytime before the review | | 7 | **D-129(iii) ACL** | Reconsider tagged-identity + star ACL at the redeploy IFF Headscale access is obtainable | redeploy, access-gated | | 8 | **D-068 item 1** | Re-baseline the V1-V5 probes opportunistically (Q2 path stays Roosevelt) | low priority | | -- | **Group 4 (18 rows)** | Deferral CONFIRMED -- bare-metal / scale / version / Magnum-bound; no action | Roosevelt | | -- | **D-019 / D-042 / D-010** | Record hygiene only | -- | **Bottom line:** the operator's instinct is right for a specific, bounded subset. The **re-IP redeploy is the lever** -- it makes the *build-process* deferrals (D-137 revocation, D-142 vault-QoL, D-136 v6 octet, D-069 custodian) actionable now, and it makes the D-129(iii) tailnet-ACL worth reconsidering because the collision proved the exposure. The **analysis-only** items (D-131 sub-4, D-140 provider read, D-068 probes) can be done now regardless. But the **majority (Group 4, 18 rows) genuinely stay** -- they are bare-metal / scale / version / Magnum-bound and the redeploy is still nested VMs, so reevaluation confirms rather than overturns them. The reevaluation's honest yield is **~4 pull-forwards (D-137/D-142/D-136-octet/D-069-custodian) + ~3 analysis-now (D-131-sub4/D-140/D-068-probes) + 1 access-gated reconsideration (D-129(iii) ACL)**, not a wholesale un-deferral. --- ## 7. Full raw inventory (from the exhaustive sweep) *Section A = held to Roosevelt/next-deployment/end-of-deployment; Section B = held to a specific VR1 step (near-term, not future-deployment); Section C = checked, NOT held.* **Section A (future-deployment held):** D-010 (NetBox merge-back, end-of-deploy, :204); D-019 (Designate, v2/Roosevelt, :384 -- superseded for VR1 by D-106); D-029 (Keystone SSO, Roosevelt, :535); D-052 (corosync ring :899; live-migration plane + QEMU TLS :901); D-059 (four-NIC collapse, Roosevelt sheets, :1090/:1104); D-068 (item1 Q2 path :5813-5819; item2 listener TLS :1660; item3 AppRole :1665); D-069 (custodian assignment/SEC-003 :1769; auto-unseal :1786); D-100 (netem profile :2239); D-104 (Juju HA :2808); D-108 (rbd-mirror HA :3049); D-121 (Vault Raft-vs-etcd :4542/:4628); D-129 (os-frr :5411; metal-edge profile :5439; security hardening :5443; two-router HA :5548; source-IP :5553; tagged/ACL :5579-5611); D-131 (sub-4 + arch review :5677-5683); D-132 (Q1 HA sub-qs / Q2 / Q3 :7137-7172); D-133 (part 2 hardware NIC :5842-5847); D-136 (automation F2/F3; octet convention; Jenkins placement :6421-6426/:6709); D-137 (rotation/revocation post-teardown :7008); D-139 (VPN :e0 :7649; external v6 routing :7403); D-140 (OpenTofu-Juju, end-of-deploy :7783); D-142 (vault-init QoL, next opportunity :8034). **Section B (VR1-step held, near-term -- NOT future deployment):** D-129 edge profiles (phase-2 :5434); os-node_exporter (phase-6 Step 10 :5441); D-135 item 2 images/simplestreams (Stage 5 :6267); D-135 item 3 charmhub/snaps (measure-at-Stage-5 :6270); D-134 v6 bands (after the GUA carve :6014). **Section C (checked, NOT held):** D-042 (discharged -- 1.4.0 shipped, :665); D-134 (applies now; VIP headroom is a Roosevelt-analog only). Excluded per scope: D-105 and the many "[ARCH] a Roosevelt build session greps this" A1-test lines (ADOPTED-and-apply-now). --- ## 8. Advisor review + consensus (corrections visible) *(Terminology note, RESOLVED 2026-08-09. The DRAFTING advisory pass on this review ran while the `advisor()` tool was configured as **Opus 5** (confirmed by the operator). A later RECHECK pass -- after the operator moved the advisor to **Fable 5** (`/advisor` output in-transcript) -- re-verified this review's findings (SEC partition, Group-4 reasoning, the D-129(iii) model) and confirmed them; its one discriminating question ("do hardware specs exist yet?") produced Section 0.1. Earlier drafts mislabelled the Opus-5 passes "fable advisor" per an inherited memory convention; that was wrong. Name a model only when its configuration is confirmed.)* **What the advisor caught on the drafted review, and what changed:** 1. **Unplaced inventory items (the same completeness class as last review's "sums to 28").** D-029 (Keystone SSO), D-068 item 2 (listener TLS), and D-068 item 3 (AppRole) were in the Section 7 inventory but in NO recommendation group. Fixed: all three added to Group 4 with their actual gating reasons (D-029 is Magnum-deferred + needs the Roosevelt cloud-internal- DNS/cert foundation, only partially advanced by D-106; D-068 items 2/3 are named Roosevelt Vault-standup requirements). 2. **D-069 conflation.** The draft merged the custodian ASSIGNMENT (operator input, decidable now) with AUTO-UNSEAL (a separate, version-bound future decision) in one Group-1 item. Recommending them together implied the redeploy could settle auto-unseal, which it can't. Split: custodian -> Group 1; auto-unseal -> Group 4 (coupled to the D-068 Q2 vault-version path, since transit/KMS auto-unseal capability is version-bound). 3. **D-069 deferral history missing as a counterweight.** Added: SEC-003 was operator-deferred 2026-07-06 and reaffirmed, and gates D-011's full close -- so the recommendation reads as a standing choice to revisit, not an oversight to fix. 4. **D-136 half-move.** Only the octet-convention half is a Group-1 pull-forward; the automation/CI (Jenkins) half is coupled to D-132 (which stays) and belongs in Group 4. Fixed both places. **CONSENSUS -- the agreed final position (both reviewers):** - The **"next deployment != the re-IP redeploy"** disambiguation is what makes this a reevaluation rather than a wholesale un-deferral, and it holds. Group 4's confirmations are correctly bare-metal/scale/version/Magnum-bound and are NOT softened. - The honest yield is a **bounded** set: ~4 build-process pull-forwards the redeploy makes actionable, ~3 analysis-now items, and 1 access-gated reconsideration (D-129(iii) ACL, where the collision changed the risk calculus but the Headscale-access blocker did not). - **The model to reuse (D-129(iii)):** when a project change bears on a held decision, state the changed risk calculus AND the unchanged blocker, and SURFACE for operator decision rather than recommending an un-defer the blocker won't allow. - No new D-numbers are warranted by this review; the pull-forwards that need a ruling to un-defer (D-069 custodian; D-129(iii) ACL) are operator-gated GA-R5 exchanges.