| 2026-08-10 |
D-101 AMENDMENT RULED (GA-R5): metal-admin commissioning TARGETS IPv6 for the 10.13 redeploy (gated)
...
Operator reconsidered D-101's "PXE is v4-first" clause on the pass6 fresh-
feasibility evidence (not the prior ruling). GA-R5 exchange, exact utterance:
"Adopt v6 (gated on live test)".
RULED: metal-admin node commissioning for the 10.13 redeploy TARGETS IPv6 (UEFI
+ DHCPv6 + HTTP boot), GATED on a one-node canary (DHCPv6 -> UEFI HTTP boot ->
enlist -> commission -> READY, captured) with v4 fallback before any fleet
commit (hard rule 2 -- no fleet commit on an unproven-on-this-cloud path). The
ungated full-fleet option was NOT chosen.
Basis: pass6 research found no MAAS-side blocker at 3.7.2 for DHCPv6
commissioning (historical bugs closed 2017/3.1), rack<->region v6 feasible-now
(source prefers AF_INET6), and the only hard blocker is legacy-BIOS PXE (Intel
firmware) -- avoided by UEFI, which we set on the VR1 node VMs. D-101's clause
was an unmeasured judgement, not a capability ceiling.
Reconciliation: AMENDS D-101 (PXE-v4-first clause only; IPv6-primary principle +
family matrix unchanged -- this ADVANCES "v6 wherever possible"); CONSISTENT
D-139 (metal-admin plane stays dual-stack; only the boot-path family shifts);
moots the standalone "soften D-101 PXE wording" DOCFIX (this amendment IS that
correction, now ruled). provider-public needed NO reconsideration -- D-101
already rules it dual-stack + native v6 GUA ext_net (v4 retained for external
v4-internet only).
Owed at redeploy design time (logged, not built): UEFI (OVMF) node-VM loader;
DHCPv6 + MAAS HTTP-boot on the metal-admin commissioning range; the canary test
+ captured evidence as a new gate. Still-owed DOCFIX (independent of A): the
stale OVN "No" row in charm-ip-family-compatibility.md.
CURRENT-STATE updated in the same commit (GA-R1 C1). repo-lint 0-fail.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
IPv6 FEASIBILITY re-check (pass6, web-researched) -- CORRECTS pass5's reliance on prior rulings
...
Operator flagged that the pass5 IPv6 review followed prior rulings instead of
freshly assessing feasibility on the ruled links. Confirmed: pass5 cited
D-101/D-139 ("PXE v4-first", "provider dual because internet=v4") as the answer
and punted the researchable question. This pass researches ACTUAL platform
capability (upstream docs/source/bug-trackers, deployed versions: MAAS 3.7.2,
Juju 3.6.27, Caracal 2024.1, OVN 24.03.2, OPNsense 26.7, Ceph Reef), ruling-
independent, with real citations (WebSearch/WebFetch throughout).
Headline: IPv6 is substantially MORE feasible than the prior rulings held.
- metal-admin IPv6 commissioning FEASIBLE-WITH-WORK on UEFI (no MAAS blocker
@3.7.2; only LEGACY-BIOS PXE is a firmware blocker, avoidable via UEFI);
MAAS rack<->region v6 FEASIBLE-NOW (source prefers AF_INET6). -> D-101's
absolute "PXE v4-first" is an overstated judgement, not a capability limit.
- provider-public v6 FEASIBLE-NOW via direct GUA routing (v6 uses NO floating
IP); D-139's "dual because internet=v4" conflated provider-network family
(v6-capable now) with external v6 internet reachability (the only true v4 need).
- Octavia LB VIP v6 FEASIBLE-NOW; hacluster API-VIP FEASIBLE-WITH-WORK (one charm
bug LP#2111852); uplink edge FEASIBLE-WITH-WORK (OPNsense ready; routed not NAT66).
CONFIRMED still-hard (fresh check validated the ruling): juju LP#1723240 live-
verified still open in 3.6.27 (D-141 holds); external v6 internet (deferred).
NEW: Ceph binds one family per daemon -> v6 cross-DC replication needs the whole
cluster single-family (DEC-24 constraint, previously unassessed).
Findings CHALLENGE D-101 (PXE) and D-139 (provider-public) framings -- surfaced
for operator RECONSIDERATION, NOT ruled (GA-R5). Two DOCFIX candidates flagged
(stale OVN "No" row vs the repo's own geneve proof; soften D-101 "PXE v4-first").
pass5 note annotated as CORRECTED. D-144 owed section + CURRENT-STATE updated
(GA-R1 C1). Deliverables: pass6-w1/w2/w3 + pass6-ipv6-feasibility-note. repo-lint
0-fail.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
IPv6-unlock design note (pass5, read-only) -> recorded under D-144 owed items
...
Focused 3-worker read-only pass enumerating the address-family surfaces of the
flat Option-1 topology (D-144) and which the collapse unlocks for IPv6.
Honest headline: the collapse unlocks LITTLE new IPv6. Of a 19-surface family
matrix, only the MAAS power-dial reach path is a clean collapse-caused v6 unlock
-- and it is UNVERIFIED, gated on DEC-15. No proposed v6 flip conflicts with a
standing ruling.
Genuine unlocks (design inputs folded into D-144's owed DECs):
- DEC-15: power-dial reach CAN go v6 (qemu+ssh to vcloud sshd off any plane
bridge) -- prefer v6, verify the address.
- DEC-14/16: the (a) control + SEC-010 successor are v6-native by construction
(nftables `inet`); and the UNRULED D-124 transit-overlay family (v6 candidate
f00::/40 reserved in the apex) should be decided on the same leg they govern.
- DEC-24: cross-DC replication carrier + its still-open D-139 v6-route are the
SAME leg -- resolve together.
NOT unlocked by the collapse (different layers, do NOT credit D-144): D-139's
plane family matrix, the geneve-over-v6 fix, and the LXD-container/juju LP#1723240
gap (D-141). metal-admin PXE stays v4 by ruling; v6-only MAAS commissioning is
UNVERIFIED (not asserted impossible). Uplink NAT stays v4 (simulated ISP).
Deliverables: pass5-w1/w2/w3 + ipv6-unlock-design-note-20260810.md. D-144 owed
section + CURRENT-STATE updated (GA-R1 C1). Read-only; nothing ruled or built.
repo-lint 0-fail.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-144 RULED (GA-R5, 3 exchanges): container-layer elimination ADOPTED -- supersedes D-123 Model B
...
Rulings landed 2026-08-10, each its own GA-R5 exchange with the operator's exact
utterance (no batching):
- DEC-01 "New D-144, supersedes D-123" -> mint D-144, flatten Model B to
Option 1 for the 10.13 redeploy
- DEC-11 "(B) shared-outer + per-DC-flat" -> tofu root shape
- DEC-13 ".8 / vr1-dcN-client" -> client-VM octet+name (D-134 amendment)
D-144 (docs/design-decisions.md): full entry with the three exchanges, the shape
adopted, the accepted power-key blast-radius tradeoff named in the body (GA-R3 A1),
the reconciliation ledger, and the OWED items (DEC-15 power-key mechanism incl.
reach + SEC-034; DEC-14/16 the (a) control; DEC-08/09 rack/D-131 retirement,
live-re-measure-gated; DEC-24 dc0<->dc1 mesh + cross-DC Ceph path; 13 owed
artifacts + 9 owed live measurements). This ruling DECIDES the shape and builds
NOTHING -- Model B stays the LIVE shape until the redeploy executes (hard rule 1).
Reconciliation recorded in D-144's ledger + append-only cross-notes:
D-123 SUPERSEDED, D-125 TERMINATED, D-128 AMENDED (Plane-2 shrink); D-134 gains a
dated .8 amendment. Precedent for mint-not-amend: D-143.
CURRENT-STATE.md updated in the same commit (GA-R1 C1): container-elim block flips
"[ARCH] ruling OWED" -> "CORE RULED / D-144 ADOPTED", next-free now D-145.
repo-lint 0-fail; ledger-scan confirms D-144 registered.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-09 |
Fable 5 advisor recheck: results CONFIRMED + edits (C.2 seen-and-rejected, advisor-identity resolved, D-137 precision, redeploy previews captured)
...
Operator moved the advisor from Opus 5 to Fable 5 and requested a recheck. Fable 5
independently re-verified and CONFIRMED this session's findings (SEC partition=28,
P5=11 with the 101->121-by-design reconstruction, live-check positive controls,
D-143 reconciliation verbs). No result overturned. Edits it surfaced:
- D-143 C.2: added the SEEN-AND-REJECTED note (operator "Octet-preserving confirmed")
-- the contiguous-/19 regularization alternative was considered and not taken.
- Advisor-identity notes RESOLVED (open-items + roosevelt Section 8, memory): the
drafting passes were Opus 5 (NOT "fable" -- that inherited label was wrong); the
recheck pass is Fable 5 (operator-configured, /advisor in-transcript). Do not
retro-label the Opus-5 rounds as Fable.
- D-137 precision: the teardown discharges only the REVOCATION leg (DC-substrate);
the ROTATION leg for persistent-host creds stays at v1 close.
- Roosevelt review Section 0.1 (+ CURRENT-STATE): captured two operator-previewed
changes to the redeploy -- (1) ELIMINATING the dc0/dc1 container layer this rebuild
(an [ARCH] D-122/D-123 change altering D-143 execution topology; owed a decision at
redeploy planning), and (2) a PRE-ROOSEVELT BARE-METAL TEST following the redeploy
(specs in days), which compresses the Group-4 horizon to weeks-away. Hardware specs
"not yet" -> Group 4 STANDS for this redeploy.
REVERT: git revert this commit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-143 RULED (GA-R5): VR1 re-IP 10.12.0.0/16 -> 10.13.0.0/16 -- AMENDS D-115 premise, TERMINATES D-101 v4-inherit; apex fork B2, lib-net (i)
...
Operator ruled the re-IP in two exchanges (option selections are the exact
utterances, recorded verbatim in the D-143 Status block):
- Exchange 1: "Accept evidence + adopt 10.13" -- adopts 10.13.0.0/16 (octet-
preserving 10.12.a.b->10.13.a.b) and ACCEPTS the tailnet+apex measurements as
sufficient for owed check #3 (VR0 internals, tailnet-only/unreachable).
- Exchange 2: C.1 "B2: new 'Cloud -- VR1 rebuild' role" (10.13 gets its own NetBox
role; Cloud stays 10.12-only, no live record re-labelled); C.3 "(i) Keep flat
defaults at 10.12; VR1 arms get full 10.13 blocks" (preserves lib-net.sh line-37
invariant).
Reconciliation: AMENDS D-115 (factual premise; role-based ruling holds),
TERMINATES D-101's v4-inherit clause, CONSISTENT-WITH D-124 (routes re-point) +
D-134 (survives, endorses the octet-preserving map).
Live evidence at ruling time (2026-08-09, operator-authorized read-only): apex
10.13=0/10.12=149; tailnet no 10.13 overlap, the 10.12 collision reproduced as
positive control. Check #3 accepted-not-run (recorded blind spot).
NOT EXECUTED (hard rule 1): B2 apex re-carve, lib-net.sh (i) + F13 comment fix,
R16 naming-collision DOCFIX, D-124 route re-point, R7 teardown revocation -- all
subsequent gated steps. CURRENT-STATE section-1 banner updated (GA-R1 C1);
next-free D now 144.
REVERT: remove the D-143 block from docs/design-decisions.md and revert the
CURRENT-STATE section-1 banner to "NOT YET RULED".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-139 AMENDMENT (2026-08-09, GA-R5): geneve-over-v6 confirmed viable; containerized chassis need carved v6 + unbracketed encap
...
Operator ruling (verbatim): 'D-139 amendment' (vs a new D-number). Records the 2026-08-09 live finding: geneve-over-IPv6 forwards on OVS 3.3/OVN 24.03/kernel 5.15 (VM-to-VM 8/8) once (i) containerized ovn-chassis take a carved v6 data-tenant address and (ii) ovn-encap-ip reaches OVS unbracketed (ovn-chassis 24.03 brackets it -> ofport -1). v4-forced is off the table. Gate scripts/geneve-encap-assert.sh (family + tunnel ofport) is the proof, wired into phase-04 Step 12.2. CURRENT-STATE section 1 updated (D-number OWED -> RULED).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-08 |
G18 RULED (GA-R5, option b): Octavia lb-mgmt recorded out of apex scope + D-139 /64 reserved
...
Gate G18 CLOSED 2026-08-08. Operator ruled option (b): the charm-created Octavia
lb-mgmt-net (IPv6-ULA fc00::/64, charm-generated per R8, regenerates per deploy) is
deliberately charm-owned and OUT of apex scope; the separate D-139 apex GUA lb-mgmt
/64 is kept reserved (distinct MAAS-underlay object, no charm consumer). R8 not
reopened. lb-mgmt is v6-ULA, outside the 10.12->10.13 v4 re-IP. Primary record in
CURRENT-STATE G18 row; annotations on D-101/R8 + D-139. No new D-number. Prep package
docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md. Also: changelog Items 3-5
(live network-create, G18 ruling, Designate real-Stage-7 decision).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-07 |
site-tailscale: prep verb + untagged VR1 (office1-mirrored) + forwarding assertion
...
Extends scripts/site-tailscale.sh to three verbs (prep|install|check) so the
per-DC .7 subnet router is brought up exactly as the working Office1 router.
- prep <site>: install the tailscale .deb from a rack-staged copy ($TS_DEB;
the .7 has no external egress) + enable IP forwarding (/etc/sysctl.d/
99-tailscale.conf, sysctl --system) and ASSERT it took.
- tag now OPTIONAL: TS_TAG defaults empty = untagged (office1-mirrored, VR1);
install omits --advertise-tags and adds --accept-routes (office1 RouteAll);
TS_TAG=tag:subnet-router restores the D-129(iii) tagged design (Roosevelt).
- check now ASSERTS IP forwarding -- the load-bearing subnet-router property
that 'tailscale up --advertise-routes' warns-and-succeeds without, so the
route could be approved while nothing forwards to Horizon (advisor 2026-08-07).
Harness: 23/23 (new failing-direction fixtures prep-noforward, check-noforward,
check-tag-notag, prep-fromdeb, install-tag-happy). Gauntlet ALL GREEN (102);
repo-lint 0 fail.
Records the operator's untagged/office1-mirror deferral as a D-129(iii)
amendment ([OPS], tags/autoApprovers/star ACL -> bare-metal) with the verbatim
utterance. Body: docs/changelog-20260807-dc0-tailscale-install.md.
Live install NOT yet executed (staged .deb -> dpkg -> prep -> install ->
operator Headscale approval -> check).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-134 amendment: MAAS hostname naming convention (standing) + dc1 rebuild-fresh ruling
...
Operator: "Record that as the preferred naming convention going forward."
Recorded the VR1 MAAS hostname convention (set vr1-<dc>-<role>-NN ==
libvirt domain == power_id after commission/deploy; random-by-default is
not leave-it-random; standup DoD = 0 non-vr1-<dc>-* names) as a D-134
AMENDMENT (per-DC identity standard; ARCH, no new number) + lib-hosts
comment.
dc1 node-handling RULED "Rebuild fresh into dc1-region" (build region,
then power/enlist/commission/deploy the 9 nodes+juju FRESH into it, not
delete+re-enlist) -> CURRENT-STATE dc1 block + ledger NEXT.
repo-lint 0 fail; gauntlet ALL GREEN (101).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-129(iii) amendment: per-DC Tailscale operator-access rulings (a-d), both DCs
...
Record four GA-R5 rulings (2026-08-07) that pull the gap-21 per-DC Tailscale
subnet-router forward to close phase-03 Horizon properly (operator: "pull the
tailscale steps forward"; "plan and push to both DC0 and DC1"):
(a) dedicated VM at utility .7 (10.12.8.7 / 10.12.68.7)
(b) STAR -- operator->DC only (the Headscale ACL / security boundary)
(c) SINGLE router, HA scale-up PINNED
(d) SNAT ON now, source-IP preservation PINNED
These are D-129(iii) implementation sub-decisions (not a new D-number). Also:
correct the D-107 citation defect (D-107 is airgap/mirror/NTP, governs no
Tailscale; D-129(iii) governs); extend D-134's standing octet map to .7;
update the gap-21 register row and CURRENT-STATE (phase-03 does NOT close this
session -- Step 3.3 Horizon splits to its own gate row, gated on the tailnet
build + vault CA on the workstation + a browser login over the tailnet).
Records only -- no code, no cloud change. The build (site-tailscale.sh + the
.7 VM per DC + Headscale star ACL/autoApprovers + SEC row) is next.
repo-lint 0 fail; Decision C reconciliation measured read-only.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-06 |
BUNDLEFIX-057 / D-072 AMENDMENT (VR1): dashboard cluster -> metal-internal (F-CV3 RESOLVED)
...
VR1 split-metal INVERTS the D-072 cluster placement. The openstack-dashboard charm
declares no admin/internal extra-binding and no os-*-network (metadata + charmhub
docs), so apache serves its SSL vhost on metal-internal while haproxy dialed
cluster=metal-admin -> vhost-less -> plaintext (the D-072 trap, inverted). Option A
(serve metal-admin) unavailable in-deployment (no charm lever).
Retire the VR0 exception: openstack-dashboard cluster -> metal-internal (generic rule
+ the served plane). Proven LIVE before ratifying (operator process directive), then
ratified GA-R5 "Ratified, land the config-of-record".
bundle.yaml cluster=metal-internal; design-decisions D-072 AMENDMENT (VR1);
binding-reference matrix + exception RETIRED + cross-ref; CURRENT-STATE/sweep/changelog
F-CV3 RESOLVED. Verified live: provider + operator metal-admin VIPs both TLS 200
CA-verified (were plaintext); cert covers all 3 VIP IPs (resolves AH01909); units
active/idle. No harness asserts this binding. gauntlet ALL GREEN, repo-lint 0-fail.
dc1 inherits via the shared bundle (no rebind).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-134: Roosevelt-delta annotation -- LXD container addresses are auto-picked, not carved
...
Logs the operator-requested Roosevelt-delta observation from the phase-03
core-verify thread. D-134 pins node statics (per-role octet bands) and the VIP
band (.50-.99 reserved); the OpenStack control plane runs in Juju LXD containers
whose addresses are NOT pinned -- MEASURED 2026-08-06 as MAAS device interfaces in
mode=static but auto-picked from the .100-.200 pool independently per subnet, so
container octets float across planes and are not redeploy-stable. Harmless in VR1
(clients use VIPs; certs reissue to cover whatever a unit holds). Roosevelt-delta:
a bare-metal build wanting predictable container addressing would add a
per-container static reservation (a "container carve"). GA-R3: observation, no new
D-number -- annotated onto D-134.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
Stage 5 dc0: memcached 1->3 config-of-record [BUNDLEFIX-055 + DOCFIX-212]
...
Operator ruling 2026-08-06, exact utterance "3 units (restore intent)" -- restoring the
2026-07-31 memcached->3 direction that BUNDLEFIX-053 never folded and the retired
dc-ha-scaleup.yaml had carried unrealized. Found while reconciling a stale comment:
- Full merge-diff (measured) of the archived overlay vs bundle.yaml showed the ONLY divergence
was memcached (overlay num_units:3 / base 1) -- BUNDLEFIX-053 folded the HA chain but not this.
Corrects two earlier misstatements (this session): "memcached=3 in bundle.yaml" (it was 1) and
the retirement's "wholly redundant / all-keys no-op" claim (it diverged on memcached).
- BUNDLEFIX-055: bundle.yaml memcached num_units 1->3, to:[lxd:0]->[lxd:0,1,2] + the
3-independent-caches rationale (no hacluster/VIP; clients hash across the full server list).
This completes the fold, making the archived overlay genuinely, fully redundant.
provider-bundle-check 57/0 (memcached is orthogonal to the arity/VIP gates).
- DOCFIX-212: design-decisions D-121 "Left single (NOT scaled)" list -- memcached removed,
recorded as =3.
- CURRENT-STATE: records the CONFIG=3 / LIVE=1 divergence -- a live add-unit (operator wants it
deployed live) or a teardown+redeploy reconciles it. The live scale-up is a separate gated step.
Gauntlet ALL GREEN (99 harnesses); repo-lint 0 fail (1 pre-existing legacy L1 warn).
Owed: re-stage the functionally-changed bundle.yaml to the dc0 rack (gated); live add-unit to 3.
Revert: bundle.yaml memcached back to num_units:1 + to:[lxd:0]; revert the DOCFIX-212 D-121 line
and the CURRENT-STATE gap note.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
Stage 5 dc0: RETIRE + archive dc-ha-scaleup.yaml (operator-ruled; R6 superseded) [DOCFIX-211]
...
Operator ruling 2026-08-06, exact utterance "Retire the redundancy and archive." The
overlay was wholly redundant -- BUNDLEFIX-053 folded its entire content into bundle.yaml,
so applying it was an all-keys no-op deep-merge (Task-#1 post-wave review, measured).
- Archived: git mv overlays/dc-ha-scaleup.yaml -> docs/archive/dc-ha-scaleup-RETIRED-20260806.yaml
+ a do-not-deploy banner. docs/archive/ chosen explicitly (no prior overlay-archive precedent).
- design-decisions.md: GA-R5 SUPERSESSION note on D-121's R6 (original 2026-07-27 record retained
as history); fixed :503 and :4563 "overlay encodes v-a" refs -> bundle.yaml/BUNDLEFIX-053.
- Harness (tests/provider-bundle-check): T17 REMOVED (== T18 once vault-hacluster is in base);
T17b/T32/T33/T34 RE-POINTED onto good.yaml (base HA chain). T33/T34 now use the deterministic
mutate() helper, not sed-on-overlay (no silent no-op fixture; a wrong key path KeyErrors). Each
FAIL case proven to fire against the real checker message. 58->57 cases; provider-bundle-check 57/0.
- Runbook dc-dc-phase4 Step-4 note + Step-12.3(a) gate: the two-phase "base at cluster_count:1 then
apply the overlay to reach 3" model RETIRED -- base deploys 3-unit HA directly, so cluster_count:3
is the expected post-Step-4 value.
- Rendered vips overlays: edited the render SOURCE (render/values/vr1-dc{0,1}-vips.yaml, D-136) and
re-rendered (not hand-edited); overlay diff = the two comment lines only; render-drift 4/0.
Hand-maintained vr1-dc{0,1}-machines.yaml deploy-command comments + provider-bundle-check.py +
cloud-assert.sh comments + dc-dc-deployment-workflow.md item 22 reconciled.
- CURRENT-STATE: no edit needed -- active status already omits the HA overlay from the deploy input;
remaining mentions are dated historical narrative (retained as history, GA-R1).
- Also finalizes Item 3/5 changelog notes (F9 approved+staged; Task #1 recommendation ruled).
Gauntlet ALL GREEN (99 harnesses); repo-lint 0 fail (1 pre-existing legacy L1 warn).
Staging: dc0 rack vr1-dc0-vips.yaml now stale-by-one-comment vs the re-render (functionally
identical); re-syncs + sha-verifies at the next deploy per D-138 (logged, no rack write for a comment).
Revert: git mv the overlay back (strip banner) + git revert this commit + re-render vips from
reverted values.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
Task #2: commit D-020 vault-metal-only amendment; teach renderer + gates; harnesses green
...
The RULED-but-uncommitted D-020 amendment (vault METAL-ONLY, 2026-08-05) is now
committed and enforced end-to-end. Discovered mid-task that the overlays are RENDERED
from render/values/*.yaml (D-136) and hand-editing them is forbidden by the render-drift
gate -- which was ALREADY red at the part-2 close (undocumented) from that session's dc0
overlay hand-edit. Resolved by teaching the renderer, not by hand-editing (advisor-reviewed;
the amendment is ruled, so this is OPS implementation).
Vault VIP shape is now the metal PAIR (metal-admin + metal-internal, no provider-public,
no v6) across all four consumers, each with a failing-direction fixture:
- provider-bundle-check.py: per-DC/family-aware vault exception; STILL band- and
octet-uniqueness-checked (advisor caught the first draft's early `continue` disarming
octet_owner for .61 -- proven rc=0 draft / rc=1 fixed). T54/T55/T56.
- render-dc-overlays.py: name-keyed metal-only render branch (drops provider + v6);
overlays re-rendered (diff vs HEAD = exactly the one vault line each). T15b.
- pre-flight-checks.sh CHECK 1: awk name-tracking + vault metal-pair branch. T28b.
- render/values/*.yaml: vault comment (part of rendered bytes).
D-121 status 12/14 -> 14/14 in CURRENT-STATE, with the missing juju-status capture
DECLARED as an owed gap (GA-R1 rule 2) rather than papered over.
Verify: gauntlet ALL GREEN (99); repo-lint 0 fail; provider-bundle-check 58/0,
render-dc-overlays 24/0, render-drift 4/0, pre-flight-checks 32/0.
Body: docs/changelog-20260805-task2-vault-metal-only-commit.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-05 |
Close-fix 2026-08-05: add Body changelog, verify root CA (openssl), reconcile D-142 scan-visibility + durability
...
Advisor-caught close gaps against the repo's own convention:
- Body: NEW docs/changelog-20260805-vault-init-ovn-resolved.md (prior closes cite a
changelog Body: line; the 08-05 close block had Sweep: but no Body:). Ledger + CURRENT-STATE
now cite it.
- Root CA: decoded the ACTUAL pasted PEM with openssl on the rack (not a self-decode).
Confirms notBefore Aug 5 02:05:57 2026 / notAfter Aug 2 01:06:27 2036 GMT; adds sha256
75:DF:33:97:...:35:A1. as-exit as-built + CURRENT-STATE updated to measured fact.
- D-142 Status now leads "PROPOSED / OPEN" so ledger-scan surfaces it (was invisible; scan
keys the open list off the Status token) -> reconciles the close block's "4 open decisions".
- Durability line completed: voffice1 PULLED to sync (was 3321c57, 4 behind); dc0 rack
~/repo-stage unaffected (docs-only; preflight sha verified); gauntlet not owed (docs-only).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
Stage 5 dc0: vault init DONE + ovn-central RESOLVED; D-142 vault-init QoL saved
...
Live (operator-run one-shot, recorded no-secrets): phase-02-vault-bringup Steps
2.1-2.3 on the dc0 rack (-m vr1-dc0), vault active/idle, root CA generated
(valid 2026-08-05 -> 2036-08-02). ovn-central/3,4,5 ALL active -- OVN NB/SB
cluster formed; the multi-session cert saga is closed by the two fixes landed
this cycle (dc-node-etchosts Step 1.2b CN delivery + D-052 '' -> metal-admin).
Engineering saved (PROPOSED, not executed -- operator: run current commands now,
test QoL next opportunity):
- D-142 PROPOSED: vault-init workflow QoL sweep (APPROVED-IN-PRINCIPLE, IMPL
DEFERRED; R2 off-host transport UNRESOLVED). Distinct from D-068 (substrate) /
D-011.6 (manual-unseal bar).
- docs/audit/vault-init-qol-proposal-20260805.md: R1-R5 + full hidden-prompt
safety analysis + tee-write residual + pre-init writability probe + R3 harness
constraints + operator's verbatim safety constraint.
- runbook-fold-register F13: -m openstack -> -m vr1-dc0 / run-location = DC rack
(D-138) on phase-02-vault-bringup (scope stretch stated).
CURRENT-STATE + as-exec updated (L10 coupling). Security hygiene: child token in
operator paste was ttl=10m/expired -> benign, not stored. Remaining (separate):
ceph-mon/2 + ceph-radosgw/0 allocating (apt-wedge) cascade.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
D-052 RE-AMENDMENT: ovn-central '' default metal-internal -> metal-admin + network binding reference
...
- ROOT: the '' default is the MANAGEMENT binding (primary NIC + juju agent<->controller),
universal '' = metal-admin across all 56 apps. The 08-03 amendment ('' -> metal-internal,
never deployed until 08-04) left ovn-central single-legged on the isolated metal-internal
plane -> no route to controller (10.12.8.5:17070 unreachable) -> agent-binary download failed
-> ovn-central never started. Its cert rationale was already withdrawn; cert CN is fixed
independently by the /etc/hosts postruncmd (dc-node-etchosts.sh, Step 1.2b).
- bundle.yaml: ovn-central '' -> metal-admin; functional endpoints (certificates, ovsdb*,
coordinator) STAY metal-internal. provider-bundle-check 55/55, repo-lint 0 fail.
- D-052 RE-AMENDMENT 2026-08-05 recorded (GA-R5, operator utterance quoted). Scope: ovn-central
only; every other binding re-verified correct vs dataflow (ruled exceptions: D-072 dashboard,
D-106 designate:dnsaas).
- NEW docs/network-space-binding-reference.md: 6-plane roles + CIDRs + RHOSP analogs, the ''
management-binding rule, full 56-app placement matrix, dataflow confirmation, ruled exceptions.
- Stage 5 remains OPEN. NEXT: re-stage bundle to rack, re-home ovn-central on the live model,
then vault init (operator-only) -> ovn cert -> converge.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728
|
| 2026-08-03 |
correct framing: ovn-central metal-internal binding is architecturally right and STAYS; cert bug separate
...
Operator: ovn-central IS a metal-internal service by the plane's intended purpose.
D-052 explicitly categorizes OVN NB/SB DB (ovsdb*) under metal-internal;
ovn-central has no public/admin API endpoint and all functional endpoints already
bind metal-internal, so the '' default belongs there too. The metal-admin default
was an API-charm convention mis-inherited by a non-API service.
What was wrong was ONLY my premise that the rebind would fix the cert bug -- it
does not. The binding (correct categorization) and the cert failure (charm
LP #2044324, server-cert request/response) are SEPARATE. The D-052 amendment
stands on architectural grounds; the binding is retained.
CURRENT-STATE and the D-052 amendment corrected accordingly. Next: bounce the
certificates relation to force a fresh exchange against the correct single-plane
baseline.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
apply ovn-central default -> metal-internal in bundle; WITHDRAW dashboard fix (D-072)
...
Applied the ruled ovn-central fix to bundle.yaml: '' default metal-admin ->
metal-internal, with an explanatory comment citing LP #2044324 and the D-052
amendment. provider-bundle-check PASS, repo-lint 0 fail.
WITHDRAWN: the openstack-dashboard:cluster fix. On reading bundle.yaml:667 before
applying, found it is D-072 / BUNDLEFIX-011 -- a RULED, as-executed fix: horizon
renders haproxy's 443 backend on the cluster-binding address but only creates
apache SSL vhosts for the default+public addresses, so cluster on metal-internal
= dashboard VIP HTTPS dead (L4 check masks it). metal-admin is deliberate.
Reverting it would reintroduce the exact bug D-072 repaired.
OWNED: my sweep flagged it because it compared binding VALUES against generic
D-052 plane purposes without grepping the governing D-NNN -- which CLAUDE.md
explicitly requires before touching a built surface. The in-bundle comment was
right above the line. Caught by reading the bundle before applying, not by the
sweep. Sweep audit, D-052 amendment, and CURRENT-STATE all corrected: 1 real
deviation (ovn-central), 5 non-issues.
Dashboard binding UNCHANGED. Next: re-stage bundle + live juju bind ovn-central.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
D-052 amendment: ovn-central default -> metal-internal (ruled); bundle plane-purpose sweep
...
Operator ruling, exact utterance: 'ovn-central should be in metal-internal.'
Follow-on: 'Complete a bundle sweep for any other bindings that are bound to a
plane that does not match the planes intended purpose.'
ovn-central's '' default binding moves metal-admin -> metal-internal. Its
certificates + ovsdb* endpoints already live on metal-internal; moving the
default makes it single-space for cert resolution, dodging LP #2044324 (the
multi-space ovn-central cert bug this deploy hit). D-052 isolation unchanged for
every other app.
Bundle plane-purpose sweep (all 56 apps, capture
binding-plane-purpose-sweep-20260803.txt): classified every binding against
D-052's plane purposes, verified each flag against the relation topology. Exactly
ONE other real deviation: openstack-dashboard:cluster on metal-admin where D-052
places cluster peers on metal-internal (sole outlier of 14 cluster-carrying apps;
benign but off-intent) -- PROPOSED, not ruled. Four flags verified non-issues:
octavia:ovsdb-cms is dangling (no relation); ceph-radosgw public/object-store/
cluster are gateway endpoints correctly placed.
Not yet applied -- bundle edit + live juju bind are the next gated step.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
D-141 ADOPTED: IPAM allocations are dual-stack, status-distinguished
...
Operator ruling, exact utterance: "Yes, but you should expand on the record. It
should be noted that when creating future ipam allocations the IPv4 and IPv6
blocks must follow this same structure."
Immediate: the 26 GUA v6 VIP addresses D-139 step 6 created stay in the apex at
status reserved (already their measured state, no NetBox mutation) and are not
promoted to active until the v6 VIPs are live and verified.
Standing rule (the architectural half, hence a D-number under GA-R3 A1):
every IPAM allocation is authored dual-stack and the STATUS field carries the
truth -- v4 active (live), GUA v6 reserved (planned/collision-protected),
superseded ULA deprecated (history). The apex records current reality AND future
plan in one place, legible from status alone: apex driving deploy, not
back-filled to it. Four binding rules: author both families together; status
bears truth never prose; promotion gated on a NAMED capability; never delete a
reserved future-family block (it is the conversion input).
Adjacent to G18 but does not answer it -- D-141 governs allocation STRUCTURE, G18
is the separate lb-mgmt-prefix ruling still deferred-until-live. The promotion
gate for the API-charm v6 VIPs is docs/charm-ip-family-compatibility.md (juju
LP#1723240 + the per-charm fixes), which now cites D-141 as its governing
decision. Roosevelt analog: every DC's IPAM authored dual-stack from day one, v6
reserved until capable, so no DC ever needs a v4->v6 re-carve -- only a status
promotion.
CURRENT-STATE updated same commit (GA-R1 C1); next-free D 141 -> 142.
repo-lint 0 fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
| 2026-08-02 |
CORRECTION: the MAAS region is INSTALLED in the DC, never migrated
...
Operator correction, verbatim: "MAAS region gets installed directly on the DC,
it is not migrated. If you have read this somewhere we need to make sure it is
corrected so future deployments don't follow a regional migration path."
I told the operator a dc0 environment rebuild would 're-run the D-132 region
migration work'. That framing came from two surfaces, and both are now fixed:
SKILL.md carried a standing invariant headed 'A PER-DC MAAS REGION MIGRATION HAS
AN ORDERING THAT IS NOT THE OBVIOUS ONE'. SKILL.md is read BEFORE any runbook, so
a session planning DC3/4/5 would have followed a migration path that does not
exist. Reframed: the region is installed in the DC at standup and nodes enlist
into it first time. The dc0 migration of 2026-07-30 was a ONE-TIME remediation
for machines already enrolled in the Office1 region before D-132 q1 was ruled --
a state no future DC can enter. The block is retained as record only, explicitly
not as a workflow.
design-decisions.md's D-132 amendment says 'Per DC this means: install region +
PostgreSQL; re-enrol and re-commission 9 nodes; recreate the D-133 carve...'.
True only of dc0 and dc1, which already existed. Annotated in place per D-117's
treatment rule rather than rewritten. The region-target parameter half DOES
generalise -- a per-DC region must be addressed explicitly; the re-enrolment half
does not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
D-135 AMENDMENT 2026-08-02 (b): dc0 converges on the proxy NOW; mirror result is informational only
...
Operator ruling, exact utterance: "Option A, converge. We have gathered the
information we need on the mirror buildout. It will be a future implementation
but will not be used in Roosevelt but much later so keep the information as
informational only with no pin or expectation on a future deployment date."
RULED (A). dc0's artifact strategy becomes the apt caching proxy on the dc1
pattern; both DCs now run ONE strategy. The per-DC origin override is DELETED
rather than repaired -- the proxy forwards whatever URL it is handed, so
cloud:jammy-caracal (the as-built-proven value, defined once behind bundle.yaml's
anchors) works unmodified and the NO_PUBKEY problem does not exist to be solved.
Supersedes the trigger clause of amendment (a), which made convergence
conditional on a rebuild of dc0's artifact service.
The experiment is complete, so the comparison amendment (a) listed as owed at
the rebuild is owed now and is recorded as evidence. Its status is set by this
ruling: INFORMATIONAL ONLY -- no pin, no expected deployment date, not a
Roosevelt item. A later session must not convert it into a pinned item, a
gap-register row, a trigger, or a forward commitment; ledger-scan and the
forward-items register stay clean of it.
dc-mirror.sh is retained for the historical arm and its currency lesson; install
is a deliberate strategy reversal, never a repair. NOT ruled here: whether the
running mirror is torn down and when its 953 GB is reclaimed -- a separate
destructive action needing its own approval.
GA-R5: recorded and pushed before dependent work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
D-139 step 6 tool built + adversarially reviewed; 4 defects fixed. Apex NOT yet written.
...
Implements the two 2026-08-02 rulings ("Full step 6 first, then deploy" / "Deprecate both,
delete nothing"): CREATE 26 GUA VIP addresses -> read-back verify -> deprecate 26 ULA
addresses + 9 ULA prefixes. NO delete path anywhere, asserted against the artifact.
Dry run (live apex): CREATE 26 | ALREADY 0 | DEPRECATE-ADDR 26 | DEPRECATE-PFX 9. The 26
CREATE targets diff EXACTLY against the 26 GUA VIP legs in overlays/vr1-dc0-vips.yaml --
every address written is one the deploy configures. --commit has NOT been run.
AN ADVERSARIAL REVIEW RETURNED "FIX FIRST" AND WAS RIGHT ON ALL FOUR COUNTS
(docs/audit/d139-step6-tool-review-20260802.txt). Mapping logic was correct; the gaps were
preconditions and coverage.
DEF-1 CRITICAL -- --dc vr1-dc1 would ORPHAN-CREATE. Targets were computed arithmetically
and never checked to exist. Measured: dc1's GUA carve is incomplete (four provider-public
rows under 2602:f3e2:f03::/48, no :20::/64, no :21::/64), so dc1 planned 26 creates into
non-existent prefixes then deprecated dc1's only authoritative rows, rc=0, no warning. dc0
hid it because all sixteen of its targets happen to exist. Reachable via the other valid
value of a required flag. FIXED + verified live: dc1 refuses, dc0 unchanged at 26/26/9.
DEF-2 CRITICAL -- the apex-IDENTITY guard was gone. It lives in d139-gua-carve.py's main()
(:159-163) and importing a module never runs its main(), so subclassing C.NB inherited the
TRANSPORT and left the SAFETY POSTURE behind: netbox.baldurkeep.com (the v1 reference)
would have connected fine and taken writes. FIXED: identity checked before any network call.
DEF-3 HIGH -- silent under-count. One missing ULA /64 row gave CREATE=13/DEPA=13/DEPP=8 at
exit 0. FIXED: any ULA address claimed by no prefix row refuses. My first fix was itself
wrong and RUNNING it caught that -- it scanned the whole retired /48 and flagged dc1's 26
VIPs while planning dc0; the /48 is SHARED (dc0 :22x, dc1 :32x). A /60 parent deliberately
does not count as coverage: the reviewer's scenario was a missing /64 whose /60 survived.
DEF-4 HIGH -- main() had ZERO coverage; the reviewer hoisted the deprecate loops above the
create phase and the suite reported ALL PASS. FIXED: T16-T18 drive main() through a fake
client that records CALL ORDER, proven by re-running that exact mutation on a copy (T18
goes RED).
TWO OF MY ASSERTIONS COULD NOT FAIL and the review killed both. T13 asserted the ABSENCE of
a string, so a traceback satisfied it -- it passed against a tool file that did not parse;
it now requires a positive, well-formed, DIFFERENT target, and new T15 asserts the tool
parses. T14 grepped ONE file, so adding a delete to the IMPORTED d139-gua-carve.py left it
green; it now covers both.
Corrected in the ruling record (GA-R1 C2): the amendment said the GUA records would be
status=active. Measured: the live ULA VIP records are "reserved", and
dc-plane-apex-import.py:186,200 creates addresses reserved. Also corrected my own
docstring overclaim -- the 26+9 deprecations are reversible, the 26 CREATES are not.
OPEN SCOPE QUESTION, MEASURED, not a tool defect: D-139 says retire the ULA rows "in the
apex AND in MAAS"; this tool is apex-only, so step 6 is NOT complete when it finishes. MAAS
on the dc0 region holds five ULA /64s beside six GUA; four are empty but
fd50:840e:74e2:220::/64 still holds 2 allocated entries. MAAS has no deprecated status for
a subnet, so delete-or-leave is a separate operator decision.
Gates: harness 20/20 (was 14, delta = the 6 cases added); gauntlet ALL GREEN (98, manifest
recorded deliberately 97 -> 98); repo-lint 0 fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
GA-R5: D-139 step 6 "retire" means DEPRECATE -- nothing is deleted (ruling before the work)
...
Taken in a SEPARATE exchange from the ordering ruling (GA-R5: one decision per exchange --
that one settled WHEN step 6 runs, this settles WHAT it does). Committed and pushed before
any dependent work.
Operator answer, exact utterance: "Deprecate both, delete nothing".
IT HAD TO BE ASKED RATHER THAN INFERRED. D-139's list says "retire the ULA rows" and this
repo has never defined that for an IPAM OBJECT: every netbox/*.py importer uses only
active/container/reserved, "deprecated" appears nowhere, and d139-gua-carve.py:4 says "NO
deletion ever". The word could equally have meant DELETE or MARK-UNUSABLE, and those differ
irreversibly in one direction. Status choices were verified against the LIVE API before the
options were put, not assumed from documentation:
prefixes -> ['container', 'active', 'reserved', 'deprecated']
ip-addresses -> ['active', 'reserved', 'deprecated', 'dhcp', 'slaac']
STEP 6 IS THEREFORE: (1) create 26 GUA VIP ip-addresses (f02:20::50-::62 metal-admin,
f02:21::50-::62 metal-internal) status=active; (2) deprecate the 26 ULA VIP addresses;
(3) deprecate the 9 ULA prefixes. CREATE FIRST, VERIFY, THEN DEPRECATE -- reversed, there
would be an interval in which the apex marks a live VIP's only record unusable.
THE COST THE ORDERING RULING FLAGGED IS WITHDRAWN. It called step 6 the largest new surface
before a deploy because it needed a DELETE path the repo has deliberately never had. There
is now no delete path: CREATE plus STATUS-UPDATE only, never-delete preserved repo-wide,
every step reversible by flipping a status back, migration stays visible in the apex.
Recorded for a later reader: "deprecated" is ADVISORY in NetBox, not enforcing. The
functional protection against handing out an in-use GUA address comes from the 26 GUA
records EXISTING, not from the deprecation.
Tool still NOT BUILT. repo-lint 0 fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
GA-R5: D-139 step 6 runs IN FULL before the Stage-5 deploy (ruling recorded before the work)
...
Closes the exchange the 2026-08-01 ordering ruling explicitly left owed: "at least step 6 has
a deploy coupling that this ruling does not settle ... needs its own GA-R5 exchange before
Step 4". Committed and pushed BEFORE any dependent work, per GA-R5.
Operator answer, exact utterance: "Full step 6 first, then deploy".
THE 08-01 PREMISE IS NO LONGER TRUE, and the question was put on re-measurement rather than
on that text. It reasoned the VIP overlays "carry v6 VIPs in the ULA range"; measured
2026-08-02, overlays/vr1-dc0-vips.yaml has ZERO fd50: legs and 39 GUA legs, re-rendered onto
GUA on 08-02 with the rack's staged copy brought into line the same day. The deploy INPUT is
already correct; the residual coupling is in the APEX only.
MEASURED (d139-gua-carve.py --dc vr1-dc0, dry run, against the working apex office1-netbox
per DOCFIX-195): CREATE 0 | EXISTS 16 | RETIRE-REPORT 9, dependents 26 ip-addresses / 0
ip-ranges. Step 1 fully applied and idempotent. The 26 were ENUMERATED rather than inferred
from the count: all are VIP records, 13 in fd50:840e:74e2:220::/64 (metal-admin) and 13 in
:221::/64 (metal-internal), octets ::50-::62. The other three retiring /64s hold zero.
CONSEQUENCE: the Stage-5 deploy is blocked on step 6 and nothing else in the D-139 list.
Step 6 = create 26 GUA VIP addresses, delete 26 ULA VIP addresses, retire 9 ULA prefixes.
Steps 4, 5 and 7 remain sequenced after the deploy (7 necessarily -- its network-get
prerequisite needs a deployed unit).
COST, recorded because it is the argument against the option chosen: it needs a repo tool
with a DELETE path against the apex, which this repo has deliberately never had.
d139-gua-carve.py refuses to delete BY DESIGN and that refusal is why the step-1 push was
safe to run. The new tool is the largest new surface introduced immediately before a deploy
and must meet the step-1 standard: independently reviewed, dry-run first, assertions proven
able to FAIL, and CREATE strictly before DELETE so no window exists in which a live VIP is
recorded nowhere.
The tool is NOT YET BUILT. repo-lint 0 fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
GA-R5 x2: D-135 amended (dc0 converges on the proxy at rebuild); D-140 PINNED (tofu/juju)
...
D-135 amendment. Operator: "if we have to rebuild in dc0 for any reason we will be using
a proxy rather than a full mirror rebuild." The 953 GB mirror is not reconstructed; a
rebuild comes back as an apt caching proxy on the dc1 pattern. This qualifies D-135's
standing "no fallback and no later convergence" -- none while the mirror stands, but a
rebuild converges. Nothing changes today: the running mirror is verified intact and stays.
Owed at the rebuild: capture the mirror arm's outcome BEFORE dismantling it, or the
experiment D-135 existed to run produces nothing. Consequence for the fold: the phase
runbooks can carry ONE artifact strategy instead of branching per DC.
D-140 PINNED. Operator: "I accept the opentofu plan. Hardened dc0 deployment then
opentofu management with a successful tested deployment method from dc0. Something to pin
for the end of deployment, review and add opentofu management to the remaining tasks."
Order: dc0 deploys and hardens -> method tested -> proven method is the translation input
-> reviewed at end-of-deployment. Not converted now because the bundle deploy has never
completed end to end and changing the mechanism first means two unknowns at once.
Value is measurably in the model/config layer, not topology. Cost to price at review: the
provider is resource-shaped not bundle-shaped, against a measured 56 apps / 108 relations.
Provider capabilities must be read, never recalled.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
| 2026-08-01 |
GA-R5: VPN (:e0) deferred to Roosevelt design time, recorded not left silent
...
Operator utterance: "Defer to Roosevelt design time".
Recorded as a DEFERRAL rather than left open, because an unrecorded hole is exactly how
the OOB omission survived until the operator caught it. Measured basis: VPN is a
RESERVATION at both precedents, never a carved plane -- VR0 DC0 and Willamette hold the
:e0::/60 parent ONLY, no /64 and no IPv4, unlike OOB which holds /60+/64 at both. VR1's
VPN is Tailscale under D-129(iii), addressed from fd7a:115c:a1e0::/48, which this
deployment does not carve, so a VR1 :e0::/60 would reserve space with no occupant.
Consequence stated plainly: VR1's octet map diverges from VR0 and Willamette on exactly
one hextet, by decision, and ruling B's "conforms to an existing org standard" claim
should be read with that documented exception. Nothing in D-139's execution list, the
Stage-5 deploy, or any gate depends on :e0. Trigger: Roosevelt VPN design, alongside
D-132 and D-131 sub-4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
|
