diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 868a5d5..e80e871 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -7718,7 +7718,7 @@ | G16 | office1 edge `channels = []` state reconcile (the D-129 module-schema residual) | [R] operator rules the mechanism; then [V] the converged re-plan capture | operator + session | CLOSED 2026-07-21: RULED "State surgery (Recommended)" (GA-R5, session changelog item 16); executed per G6 precedent -- channels null -> [] injected, serial 29 -> 30, backup kept, guests untouched (office1-opnsense Id 2 running throughout); convergence = ZERO DIFF (`docs/audit/outer-plan-20260721-postG16-converged.txt`); section 5 re-recorded | | G17 | **Per-DC artifact source reachable FROM A NODE** -- the node-side half of Stage 4 DoD bullet 5, split out of Stage 4 by operator ruling rather than closed conditionally | [V] a NAMED executable check run from a node that has actually booted an OS on its real NICs, per DC. **RESHAPED 2026-07-27 by operator ruling (R12) -- the previous wording is superseded because it CARRIED THE WRONG SCOPE AND COULD NOT FAIL.** Three assertions per DC, each capturing output: **(1) ARTIFACT REACHABILITY, asserted on CONTENT with an exit-code predicate.** dc0 -> fetch a real PACKAGE-PATH from the mirror (e.g. `curl -fsS -o /dev/null http://10.12.8.4/ubuntu/dists/jammy/Release`), NOT the bare root. dc1 -> the NAMED check that already exists, `scripts/dc-cache-proxy.sh:210-217`'s proxied fetch of archive AND UCA `Release` with `-w '%{http_code}'`, run from the node against `10.12.68.4:3142` (the D-135-AMENDED ruled artifact path -- dc1 has NO node-facing mirror, so checking it as one would fail by design). WHY THE CHANGE: the prior text specified `curl -sI http://10.12.8.4/`, which **cannot fail** -- measured, `curl -sI` exits 0 on 404/403/500 (a planted 404 printed `404 File not found` with curl exit **0**, while `curl -fsI` exited 22), and the dc0 URL is an nginx `autoindex` root created EMPTY by `dc-mirror.sh:330` before any sync, so `/` answers 200 whether or not `last-sync.status` says OK. It reintroduced the existence-not-content class that `dc-mirror.sh check` was fixed for on the SAME DAY. The dc1 half named no command at all, though the real one already existed. **(2) NODE TIME SOURCE -- folded in here, previously homeless.** `chronyc sources` on the node shows the MAAS-served time source and NOT the DC edge, per D-129(iv). This is the surviving REPLACEMENT for struck DoD bullet 6: DOCFIX-204 struck 'NTP from the DC's own OPNsense edge' because D-129(iv) gave the edge no NTP role -- it did NOT strike time verification, and `docs/dc-dc-deployment-workflow.md:206` and `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:46` both assign the node time source to G17. Until this reshape, `chronyc` appeared ZERO times in this document, so the check two surfaces required had no home in the gate meant to carry it. **(3) An UNRECOGNISED or UNREACHABLE result REFUSES** rather than defaulting to success -- 'could not look' is never 'nothing there'. RULING (GA-R5, 2026-07-27). Question as presented: whether to fold time verification into G17 and fix the check to assert content, give time verification its own gate row, or confirm it struck and remove the conflicting surfaces. Operator answer, exact utterance: **"Fold time verification into G17 and fix the check to assert content (Recommended)"**. Both defects live in the same row and share the same ONE-TIME first-boot window, so they are fixed in one edit; splitting them risked one landing without the other. The natural trigger is Stage 5 first boot, when Juju provisions the nodes and they run apt for real; a gated MAAS rescue-boot is the alternative if it must be answered sooner | session (each boot operator-approved) | **OPEN 2026-07-27.** WHY THIS EXISTS: the DoD bullet reads "per-DC mirror reachable from nodes", but the READY-handoff ruling (2026-07-23, DOCFIX-200) leaves all 18 nodes powered off in `Ready` -- MAAS-deploy is SKIPPED and Juju provisions at Stage 5 -- so no node-side probe can run inside Stage 4 at all. GA-R6 E3 forbids a conditional close, so the remainder splits here. RULING (GA-R5). Question as presented 2026-07-27: "The node-side half of bullet 5. Nodes are powered off by the READY-handoff ruling, so no node-side probe can run as things stand. Either a gated rescue-boot check on one node per DC now (closes it inside Stage 4), or split it into its own gate row targeted at Stage 5 first boot (GA-R6 E3 explicitly permits this; a conditional close is not permitted)." Operator answer, exact utterance: **"split it into its own gate row"**. SCOPE NOTE: what stays in Stage 4 is the RACK-side half -- the artifact source answers on its own address with an attested-current sync -- which is what `dc-mirror.sh check` / `dc-cache-proxy.sh check` verify (both fixed this session to stop false-greening; capture `docs/audit/stage4-mirror-gate-20260727.txt`). G17 is NOT a Stage-5 precondition and must not be conflated with one: Stage 5's own bootstrap needs OPEN edge egress for the juju agent stream + snaps (D-135 items 2-3 unbuilt), which is a different path from the apt artifact source this gate covers. | -| G18 | **IPAM apex completeness for the Octavia lb-mgmt plane** -- does the charm-created `lb-mgmt-net` prefix get BACK-FILLED into the NetBox apex, or is that plane recorded as deliberately charm-owned and out of apex scope? | [R] ruling-type gate (GA-R6 rule 6): closes ONLY on a GA-R5 recorded ruling with the operator's exact utterance, dated, committed and pushed. **DEFERRED BY OPERATOR DIRECTION 2026-07-27 until the cloud is LIVE and IPv6 behaviour has been observed** -- it is not answerable from artifacts alone. **BLOCKING: the deployment may NOT be declared complete while this is open.** ANSWERABLE from Stage 5 onward (the prefix exists once Octavia deploys); BLOCKS the FINAL stage close / project close. | operator | **OPEN 2026-07-27.** WHY IT EXISTS: R8 ruled that Octavia creates and owns its own IPv6 lb-mgmt network. Measured consequence -- the octavia charm exposes NO CIDR, address-family or router configuration option (`create-mgmt-network`, default True, is the only related option), so the prefix is CHARM-GENERATED and cannot come from the D-111 carve. NetBox is therefore knowingly INCOMPLETE for exactly one plane. That is the authority-inversion concern the Stage-5 grounding audit's lens 7 raised (the apex being back-filled to match a deploy rather than driving it), and it is adjacent to the UNRULED D-136 NetBox-coupled render pipeline -- so ruling it early would pre-empt D-136. OPERATOR DIRECTION, verbatim: "leave this as an open decision that will need a ruling once we have the cloud live and we have a better read on the network and how everything is functioning with the addition of the new IPv6 configurations. Make this a gated decision so we cannot close the project (or whatever phase you think it best ruled in) without a ruling on this item." RELATED AND ALSO RECORDED: the absence of an lb-mgmt `:x80` prefix in the VR1 ULA carve is CORRECT under R8, not a gap -- see the D-101 R8 ruling note; a future session must not "fix" it. Options to present at ruling time: (a) back-fill the charm-created prefix into NetBox post-deploy as a documented record; (b) record the plane as charm-owned and explicitly out of apex scope; (c) fold the decision into D-136's render-pipeline ruling if that is taken first. | +| G18 | **IPAM apex completeness for the Octavia lb-mgmt plane** -- does the charm-created `lb-mgmt-net` prefix get BACK-FILLED into the NetBox apex, or is that plane recorded as deliberately charm-owned and out of apex scope? | [R] ruling-type gate (GA-R6 rule 6): closes ONLY on a GA-R5 recorded ruling with the operator's exact utterance, dated, committed and pushed. **DEFERRED BY OPERATOR DIRECTION 2026-07-27 until the cloud is LIVE and IPv6 behaviour has been observed** -- it is not answerable from artifacts alone. **BLOCKING: the deployment may NOT be declared complete while this is open.** ANSWERABLE from Stage 5 onward (the prefix exists once Octavia deploys); BLOCKS the FINAL stage close / project close. | operator | **CLOSED 2026-08-08 (GA-R5), option (b)** (was OPEN 2026-07-27) -- ruling appended at the end of this cell. WHY IT EXISTS: R8 ruled that Octavia creates and owns its own IPv6 lb-mgmt network. Measured consequence -- the octavia charm exposes NO CIDR, address-family or router configuration option (`create-mgmt-network`, default True, is the only related option), so the prefix is CHARM-GENERATED and cannot come from the D-111 carve. NetBox is therefore knowingly INCOMPLETE for exactly one plane. That is the authority-inversion concern the Stage-5 grounding audit's lens 7 raised (the apex being back-filled to match a deploy rather than driving it), and it is adjacent to the UNRULED D-136 NetBox-coupled render pipeline -- so ruling it early would pre-empt D-136. OPERATOR DIRECTION, verbatim: "leave this as an open decision that will need a ruling once we have the cloud live and we have a better read on the network and how everything is functioning with the addition of the new IPv6 configurations. Make this a gated decision so we cannot close the project (or whatever phase you think it best ruled in) without a ruling on this item." RELATED AND ALSO RECORDED: the absence of an lb-mgmt `:x80` prefix in the VR1 ULA carve is CORRECT under R8, not a gap -- see the D-101 R8 ruling note; a future session must not "fix" it. Options to present at ruling time: (a) back-fill the charm-created prefix into NetBox post-deploy as a documented record; (b) record the plane as charm-owned and explicitly out of apex scope; (c) fold the decision into D-136's render-pipeline ruling if that is taken first. **RULED 2026-08-08 (GA-R5), OPTION (b).** Question put to the operator: given R8 already ruled Octavia owns a charm-generated IPv6-ULA `fc00::/64` that regenerates per deploy (ownership/family/CIDR NOT reopened), how does the apex record this one plane? Operator's exact selection: "B: record out of apex scope + keep D-139 /64 reserved (Recommended)". CONSEQUENCE: the charm-created `lb-mgmt-net` is deliberately charm-owned and OUT of apex scope -- the apex carries a structural note (plane exists, charm-owned, ephemeral ULA prefix), NOT a concrete prefix row the deploy consumes; D-141-compliant (D-141 governs CONSUMED allocations, and states G18 is separate). The SEPARATE D-139 apex GUA `lb-mgmt` /64 (`2602:f3e2:f02:80::/64` dc0) is kept `reserved` (MAAS-underlay allocation, no charm consumer), explicitly distinct from the charm's Neutron net. NO new D-number (annotates D-101/R8 + D-139). Prep + reconciliation: `docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md`. OWED post-`configure-resources` read-only: capture actual `fc00::/64` (`openstack subnet list --tags charm-octavia`); router `external_gateway_info` (mgmt-net isolation, R8 left unasserted); `o-hm0` MTU match (LP#2018998). NOTE: G18's original deferral trigger ("until cloud live + IPv6 observed") was NOT yet met -- dc0 is a pre-`configure-resources` throwaway checkpoint; operator ruled ahead of trigger on artifacts so the ruling transfers to the 10.13 rebuild; the live observation remains available via the OWED checks. | ## 7. Version pins (measured; the authority for every pin) diff --git a/docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md b/docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md new file mode 100644 index 0000000..db157a1 --- /dev/null +++ b/docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md @@ -0,0 +1,314 @@ +# G18 -- Octavia lb-mgmt IPAM: GA-R5 ruling PREP package (2026-08-08) + +**Status: PREP ONLY. This document does NOT rule and mutates nothing.** It assembles the +quotes, options, and governing-decision reconciliation so the operator can issue a GA-R5 +ruling on gate **G18**. No D-number is minted here; no built surface is edited. + +Author context: prep for firing octavia `configure-resources` on the **dc0 throwaway +checkpoint**, ruling G18 now so the ruling transfers to the 10.13 rebuild. All facts below +are quoted from repo artifacts (path:line) or explicitly flagged as an OWED live read. + +--- + +## A. What G18 IS (and what it does NOT reopen) + +**Verbatim definition** -- `docs/CURRENT-STATE.md:7721` (gate register row): + +> | G18 | **IPAM apex completeness for the Octavia lb-mgmt plane** -- does the +> charm-created `lb-mgmt-net` prefix get BACK-FILLED into the NetBox apex, or is that plane +> recorded as deliberately charm-owned and out of apex scope? | [R] ruling-type gate +> (GA-R6 rule 6): closes ONLY on a GA-R5 recorded ruling with the operator's exact +> utterance, dated, committed and pushed. **DEFERRED BY OPERATOR DIRECTION 2026-07-27 until +> the cloud is LIVE and IPv6 behaviour has been observed** -- it is not answerable from +> artifacts alone. **BLOCKING: the deployment may NOT be declared complete while this is +> open.** ANSWERABLE from Stage 5 onward (the prefix exists once Octavia deploys); BLOCKS +> the FINAL stage close / project close. | operator | **OPEN 2026-07-27.** ... | + +**Current status: OPEN 2026-07-27** (same row). Ruling-type `[R]` gate; closes only on a +recorded GA-R5 ruling with the operator's exact utterance. + +**Operator direction that opened it, verbatim** (`CURRENT-STATE.md:7721`, echoed at +`design-decisions.md:2486-2492`): + +> "leave this as an open decision that will need a ruling once we have the cloud live and we +> have a better read on the network and how everything is functioning with the addition of +> the new IPv6 configurations. Make this a gated decision so we cannot close the project (or +> whatever phase you think it best ruled in) without a ruling on this item." + +**The pre-stated options recorded on the gate row** (`CURRENT-STATE.md:7721`): +> (a) back-fill the charm-created prefix into NetBox post-deploy as a documented record; +> (b) record the plane as charm-owned and explicitly out of apex scope; (c) fold the +> decision into D-136's render-pipeline ruling if that is taken first. + +### What G18 does NOT reopen -- ALREADY RULED by R8 (D-101 ruling note 2026-07-27) + +`design-decisions.md:2434-2507` (the **R8** ruling note under D-101). Operator utterance, +verbatim (`:2444-2445`): + +> "I want to take a Octavia creates and owns its own IPv6 network." + +R8 settled THREE things that G18 must **not** reopen: +1. **Ownership** -- Octavia creates and owns its own lb-mgmt network (`create-mgmt-network` + left at charm default **True**; set NOWHERE in bundle/overlays -- `:2450-2452`, confirmed + again below in B). +2. **Address family** -- IPv6 **ULA** (`fc00::/7`); the charm default is a ULA and it agrees + with D-101's "IPv6-only ULA ... Octavia lb-mgmt ... Internal, no external clients" + classification (`:2469-2472`). +3. **Prefix source** -- **charm-generated**; the charm exposes NO CIDR / family / router + config option, so the prefix "cannot come from the apex" (`:2481-2484`). + +Therefore G18's live question is **NOT "what CIDR should lb-mgmt use"** -- that is charm- +generated and ruled. G18 is **only the APEX-RECORDING question**: does the charm-generated +prefix get recorded in NetBox (back-fill), or is the plane declared deliberately charm-owned +and out of apex scope. Any option that changes the CIDR, family, or ownership REOPENS R8 and +must be flagged as such (see Section C, Option D). + +### The deferral trigger is NOT met -- state this to the operator + +G18 was deferred "until the cloud is LIVE and IPv6 behaviour has been observed." **dc0 is a +pre-`configure-resources` throwaway checkpoint** -- the lb-mgmt network does not exist yet +and no IPv6 behaviour has been observed. The operator is choosing to rule **ahead of their +own stated trigger**, on artifacts, so the ruling transfers to the 10.13 rebuild. That is +the operator's prerogative; it is surfaced here so the condition they themselves set is not +hidden. The live observation the deferral wanted remains available later as a review item +(the OWED checks in Section F). + +--- + +## B. What `configure-resources` will CREATE, and the IPAM question precisely stated + +**The action** (`runbooks/phase-05-octavia-enablement.md:53-91`): `configure-resources` is +D-021 Phase 1; it **takes NO parameters** (`:63`). With `create-mgmt-network=true` (the +MEASURED charm default) it creates the neutron management resources the charm locates by +resource TAG (`charm-octavia`). + +**What it creates** (as-built capture from the prior deploy, `phase-05:89-99`, `:203-208`): +- `lb-mgmt-net` -- a **Neutron** network (found via `openstack network list --tags + charm-octavia`). +- `lb-mgmt-subnetv6` -- an **IPv6 ULA** subnet, `fc00::/64`, **charm-generated**, and it + **"regenerates per deploy"** (`:205` -- "a fresh IPv6-ULA on the lb-mgmt prefix + (fc00::/64; exact addr not captured this run -- the ULA regenerates per deploy)"). +- `lb-mgmt-sec-grp` -- security group(s). +- a **Neutron router** ("Router for IPv6 RA or north/south mgmt traffic" -- required for + Router Advertisement so amphorae get addresses; `octavia-ipv6-research-20260727.md:233-235`). +- `o-hm0` -- the health-manager port, a **br-int** port carrying an `fc00::/64` ULA + (`phase-05:92-95`). +- a **default amphora flavor** (charm-created alongside the network resources). + +**This is a Neutron OVERLAY network, not a MAAS/underlay plane.** It rides the geneve overlay +whose underlay is the `data-tenant` plane: `octavia:ovsdb-cms` and `ovn-chassis-octavia:data` +bind to `data-tenant` (`docs/network-space-binding-reference.md:60`), and the octavia +application itself binds to `metal-admin` (`:113`). **There is NO `octavia` binding to any +`lb-mgmt` space** (bundle.yaml octavia `bindings:` block, lines 749-762: amqp / certificates +/ cluster / ha / identity-service / internal / neutron-api / neutron-openvswitch / +ovsdb-subordinate / shared-db -> metal-internal; ovsdb-cms -> data-tenant; public -> +provider-public). This fact is load-bearing for Section D. + +**The charm control surface** (`octavia-ipv6-research-20260727.md:217-230`): "`create-mgmt- +network` (default True) is the ONLY related option ... There is NO configuration option for +CIDR, address family, router creation, or north/south control." Getting a specific prefix +"REQUIRES `create-mgmt-network: false`, and you then own the network AND the security groups +AND the ports AND the router, because resource TAGS are how the charm finds them." + +### THE IPAM QUESTION, precisely stated + +Given R8 (charm owns it; IPv6-ULA; charm-generated per-deploy prefix), the ONLY open IPAM +question G18 asks is: + +> The charm generates its own `lb-mgmt-subnetv6` ULA prefix at `configure-resources` time, +> and that prefix is NOT specified by any artifact and REGENERATES on each (re)deploy. The +> NetBox apex therefore has no allocation the deploy consumes for this plane. **Does the +> apex (a) back-fill the charm-created prefix as a record, or (b) record the plane as +> deliberately charm-owned and out of apex scope?** -- plus the D-139 sub-question in +> Section D (what becomes of the *separate* apex-carved `lb-mgmt` GUA prefix). + +--- + +## C. Options for the lb-mgmt IPAM (with re-IP portability) + +Re-IP frame: the charm net is IPv6-ULA `fc00::/64`, Neutron overlay, regenerating per deploy. +The re-IP is **v4** (`10.12.0.0/16` -> `10.13.0.0/16`). **Zero intersection** -- the v4 re-IP +cannot touch the lb-mgmt prefix, and the lb-mgmt prefix cannot constrain the re-IP, in either +direction. Portability differences below are therefore about *record staleness across the +teardown/rebuild*, not about v4 addressing. + +### Option B (RECOMMENDED) -- record the plane as deliberately charm-owned / out of apex scope +- Accept `create-mgmt-network=true` (charm default, R8-ruled). The apex carries a NOTE for + the plane -- "charm-owned; prefix charm-generated ULA, ephemeral per deploy; not an + apex-driven allocation" -- rather than a concrete prefix row the deploy is expected to + consume. +- **Re-IP portable: YES, natively.** Nothing to migrate; the note is deploy-agnostic and + survives the 10.13 rebuild unchanged. The charm regenerates its ULA on the rebuild exactly + as on dc0. +- Aligns with R8 (no reopen), and is D-141-compliant (see D). + +### Option A -- back-fill the charm-created prefix into NetBox post-deploy +- After `configure-resources`, capture the actual generated `fc00::/64` and record it in the + apex as an `active` (or observed) allocation. +- **Re-IP portable: NO, in the naive form.** Because the ULA **regenerates per deploy**, a + back-filled concrete prefix is **stale the moment dc0 is torn down** and wrong for the + 10.13 rebuild -- which is precisely the rebuild the operator is ruling for. A concrete + back-fill would have to be re-captured and re-written on every deploy. +- Survives ONLY as a **structural** back-fill (record "the plane exists, charm-owned, prefix + ephemeral" without pinning the concrete /64) -- which **converges to Option B**. So A-naive + is close to disqualified for this project's stated purpose; A-structural == B. + +### Option C -- fold into D-136's render-pipeline ruling +- **MOOT / effectively closed.** D-136 is **ADOPTED 2026-07-27, option (D)** + (`design-decisions.md:6401-6419`). The G18 deferral note's premise -- "ruling it early + would pre-empt the *unruled* D-136" (`:2491`) -- **no longer holds**; D-136 is ruled. There + is no open D-136 ruling to fold into. Listed for completeness; not a live path. + +### Option D -- carve a dedicated lb-mgmt prefix and hand it to the charm (REOPENS R8) +- Set `create-mgmt-network=false` and point octavia at a pre-created Neutron network on a + chosen prefix (e.g. the D-139 apex `lb-mgmt` GUA `/64`, or a D-134-style carved band). +- **This REVERSES R8.** Per the research capture (`:228-230`) it drags ownership of the + network AND security groups AND ports AND router onto the operator, and R8 explicitly chose + the opposite ("Octavia creates and owns its own IPv6 network"). It also changes the family + (charm ULA -> whatever is carved). +- **Re-IP portable: only if the carved prefix is v6** (a v4 carve would enter the re-IP blast + radius). But portability is moot -- this option is listed to be **explicitly rejected as a + reopen of a GA-R5 ruling**, not recommended. Included so the operator sees the full space. + +--- + +## D. Governing-decision reconciliation (D-021, D-134, D-139, D-141) + the two-objects finding + +### D-021 (Octavia amphora image pipeline) -- `design-decisions.md:507-517` +D-021 governs the **amphora IMAGE** (charm-native `octavia-diskimage-retrofit`, +`use-internal-endpoints: true`, `image-format: raw`, tag `octavia-amphora` matching octavia's +`amp-image-tag`). It is the pipeline that `configure-resources` (D-021 Phase 1) precedes. **It +does NOT touch lb-mgmt IPAM** -- it is about the image the amphorae boot, not the management +network they attach to. Reconciliation: **no option in C conflicts with D-021.** All options +leave the amphora image pipeline unchanged. (`amp-image-tag: octavia-amphora` and +`loadbalancer-topology=SINGLE` are the MEASURED octavia config; neither is an IPAM lever.) + +### D-134 (per-DC octet bands) -- `design-decisions.md:5858-6200` +D-134 is a **v4** per-role octet-band scheme over the **SIX** MAAS DC planes. **It allocates +NOTHING for an lb-mgmt / amphora-management network.** Confirmed in the as-built model: +`scripts/lib-net.sh:22-31` -- `PLANE_CIDRS` and `PLANE_NAME` list exactly six planes +(provider-public, metal-admin, metal-internal, data-tenant, storage, replication); there is +**no lb-mgmt plane**, and `lbaas` is listed in `STALE_SPACES` (`lib-net.sh:34`). D-134's bands +(`.1-.3` infra / `.4-.49` utility / `.50-.99` VIP / `.100-.200` nodes / `.201-.254` dynamic) +have **no lb-mgmt band**. **lb-mgmt is outside the D-134 carved-plane model entirely.** + +### D-139 (full-GUA re-carve) -- `design-decisions.md:7254-7497` -- THE COLLISION FINDING +D-139 ruling A adds `lb-mgmt` as a **"NEW plane"** in its family matrix (`:7282`) and ruling B +carves it an apex **GUA** `/64`: parent `f0X:80::/60`, dc0 `2602:f3e2:f02:80::/64`, dc1 +`2602:f3e2:f03:80::/64` (`:7312`). Execution step 5 (`:7489`): "**Carve `lb-mgmt` its +VLAN/space/subnet. It has never had one anywhere, in either family.**" + +**This is NOT a contradiction with R8 -- it is TWO OBJECTS SHARING ONE NAME:** +- **D-139's `lb-mgmt`** is a **MAAS underlay plane** (a space / VLAN / subnet -- the vocabulary + of step 5, sitting in the matrix beside storage/replication/data-tenant, all MAAS spaces). +- **R8's / the charm's `lb-mgmt-net`** is a **Neutron overlay network** the charm creates and + owns, riding the geneve overlay on the `data-tenant` underlay (Section B). + +The discriminating evidence: **octavia binds to NO `lb-mgmt` space** (bundle.yaml:749-762; +binding-reference:60,113). So the D-139 apex GUA `lb-mgmt` `/64` **has no charm consumer**, and +**D-139 step 5 is unexecuted** (the v6 GUA carve is largely unexecuted; `lib-net.sh` still +holds six planes with no lb-mgmt). This yields a **sub-question the operator's ruling should +also settle**: what becomes of the carved-but-unconsumed D-139 apex `lb-mgmt` GUA `/64`? +Candidate dispositions to put alongside the main options: keep it as a **`reserved`** +architectural allocation under D-141 (intent recorded, no live consumer) with a note that it +is NOT the charm's mgmt network; or record that the D-139 "lb-mgmt plane" and the charm's +"lb-mgmt-net" are distinct and the former is an underlay reservation only. + +### D-141 (author dual-stack; apex drives the deploy) -- `design-decisions.md:7920-7962` +D-141 requires apex allocations to **drive** the deploy, not be back-filled to match it -- "the +authority direction G18/lens-7 requires" (`:7937-7940`). At first glance Option B (record as +out-of-scope) looks like conceding apex incompleteness. It is not: **D-141 governs allocations +the deploy CONSUMES.** The charm's mgmt prefix is one no artifact can specify and the charm +regenerates per deploy -- it is **not an apex-driven allocation**, so recording it as +deliberately out of scope is **D-141-COMPLIANT, not an exception.** D-141 says so itself +(`:7958-7960`, quote it in the ruling): + +> "**Adjacent to gate G18** (IPAM apex completeness, deferred-until-live): D-141 governs the +> STRUCTURE of apex allocations; G18 remains the separate ruling on the charm-created lb-mgmt +> prefix and must not be treated as answered by this." + +That line is the license to rule Option B without contradicting D-141. (Note the tension: the +D-139 apex GUA `/64` IS an apex allocation -- so the D-141 "author dual-stack / reserved +until consumable" discipline applies to *that* object, which supports keeping it `reserved` +rather than deleting it. Two objects, two treatments.) + +--- + +## E. The GA-R5 ruling QUESTION drafted for the operator + +**Reminder (GA-R5): ONE decision; reconcile the governing decisions; the operator's exact +utterance is recorded verbatim at ruling time.** Do NOT mint a new D-number (Section F). + +> **G18 -- Octavia lb-mgmt IPAM apex recording.** R8 (D-101 note, 2026-07-27) already ruled +> that Octavia creates and owns its own IPv6-ULA lb-mgmt network (`create-mgmt-network=true`), +> with a **charm-generated `fc00::/64` prefix that regenerates on every deploy**. This ruling +> does NOT reopen ownership, family, or CIDR. The open question is **how the apex records +> this one plane**: +> +> - **(B) RECORDED OUT OF APEX SCOPE [RECOMMENDED]** -- the charm-created `lb-mgmt-net` is +> declared deliberately charm-owned; the apex carries a structural note (plane exists, +> charm-owned, prefix ephemeral ULA), not a concrete prefix row the deploy consumes. +> D-141-compliant (D-141 governs consumed allocations; this is not one). Re-IP portable to +> 10.13 natively. +> - **(A) BACK-FILL THE CONCRETE PREFIX** -- capture and record the actual `fc00::/64` after +> `configure-resources`. NOT portable: the ULA regenerates per deploy, so the record is +> stale on the 10.13 rebuild. (Its portable form -- a structural, non-pinned record -- +> collapses into B.) +> - **(C) FOLD INTO D-136** -- MOOT; D-136 is already ADOPTED (2026-07-27, option D). +> - **(D) REOPEN R8** (create-mgmt-network=false + operator-carved prefix) -- reverses a GA-R5 +> ruling and transfers ownership of the net/secgroups/ports/router to the operator. Listed +> to be explicitly rejected. +> +> **Sub-question (D-139):** the D-139 apex GUA `lb-mgmt` `/64` (`2602:f3e2:f02:80::/64` dc0) +> is a **MAAS-underlay plane with no charm consumer** -- distinct from the charm's Neutron +> `lb-mgmt-net`. Ruling B should also state its disposition: keep as a **`reserved`** +> architectural allocation per D-141, explicitly noted as NOT the charm's mgmt network. + +**RECOMMENDED DEFAULT: Option (B), out of apex scope, + keep the D-139 GUA `/64` as a +`reserved` underlay allocation noted distinct from the charm net.** + +**One-line rationale:** the charm-generated ULA regenerates per deploy so it is not an +apex-driven allocation (D-141 governs only consumed allocations, and says G18 is separate); +B is the only option that is both R8-aligned and natively portable to the 10.13 rebuild the +operator is ruling for. + +--- + +## F. OWED read-only checks + D-number status + +### No new D-number needed (grep reported) +Highest live decision number is **D-142** (`design-decisions.md`; the apparent "D-202" is a +false-positive substring of the filename fragment `RETIRED-20260806`). **Next-free would be +D-143** IF one were required -- **but it is not.** G18 is a `[R]` ruling-type gate that closes +on a GA-R5 ruling recorded against **existing** decisions: annotate the **D-101 / R8** ruling +note (the decision that owns lb-mgmt ownership/family) and, for the two-objects finding, add a +reconciliation note on **D-139** (the decision that carved the apex GUA `lb-mgmt` plane). This +matches the caught near-miss in auto-memory (#19: do not mint a D-number for what is really an +amendment to a ruled parent). **The operator may overrule and mint D-143 if they judge this a +standalone architectural decision.** GRAND TOTAL: prep proposes NO mint; reports D-143 as +next-free. + +### OWED live read-only checks (name them; do NOT run the action; run AFTER `configure-resources`) +1. **Capture the actual generated prefix** (settles what B's note / A's back-fill would + reference): `openstack subnet list --tags charm-octavia -f value -c Name -c Subnet` + (expect `lb-mgmt-subnetv6`, an `fc00::/64`). Read-only `list`. +2. **Settle R8's explicitly-unasserted external-gateway / isolation question** + (`design-decisions.md:2503-2507`, `octavia-ipv6-research-20260727.md:232-242` -- "cannot be + asserted that the charm never attaches an external gateway"): + `openstack router list --tags charm-octavia` then inspect the router's + `external_gateway_info` (read-only `show`). Confirms the mgmt net is isolated. +3. **Standing MTU obligation (adjacent, NOT a G18 input)** -- LP #2018998 recurred on our + exact pin (`design-decisions.md:2494-2501`): verify `o-hm0`'s MTU MATCHES `lb-mgmt-net`'s, + measured. This is a Stage-5 Octavia-step obligation independent of the G18 ruling; noted + here only so it is not lost. + +### Items I could NOT verify from artifacts (flagged, not guessed) +- The **concrete** charm-generated `fc00::/64` for the dc0 checkpoint does not exist yet + (`configure-resources` not fired) -- check #1 above captures it post-action. +- Whether the charm attaches an external gateway on its own -- check #2 (R8 left this + unasserted by design; it needs the live router or the charm source). + +--- + +*Prep complete. No ruling issued, no D-number minted, no built surface edited, nothing +committed. Operator rules from Section E; record the exact utterance per GA-R5.* diff --git a/docs/changelog-20260808-dc0-activation.md b/docs/changelog-20260808-dc0-activation.md index 7f35818..48621ee 100644 --- a/docs/changelog-20260808-dc0-activation.md +++ b/docs/changelog-20260808-dc0-activation.md @@ -49,10 +49,8 @@ scripts/phase-04-network-verify.sh tests/phase-04-create/ tests/phase-04/` restores the hardcoded-`admin` scripts and the prior harnesses. Behaviour reverts to VR0-only. -**OWED (not in this item -- live, operator-gated):** register the `vr1-dc0-region` -maas CLI profile ON the rack (credential one-shot, SEC-safe -- generated on hot-kid, -piped to `maas login`, never printed), then run `MAAS_PROFILE=vr1-dc0-region -scripts/phase-04-network-create.sh` on the rack. Task #1 remains OPEN until that runs. +**DONE (live, operator-authorised) -- see Item 3:** the `vr1-dc0-region` profile was +registered on the rack (SEC-safe stdin key) and network-create ran. Task #1 COMPLETE. **Rebuild-plan finding (LOGGED, not executed):** the outer substrate hosts `vvr1-dc0` / `vvr1-dc1` are currently MAAS rack controllers under the OFFICE1 `admin` @@ -89,3 +87,87 @@ **Revert.** `git rm docs/audit/reip-1013-ga-r5-ruling-prep-20260808.md` (analysis artifact only; nothing consumes it). + +--- + +## Item 3 -- LIVE dc0 activation: rack maas profile + phase-04 provider network created + +As-executed record (run-logged is structurally unavailable in this harness -- the +interactive `script -aqe` subshell cannot wrap tool-driven Bash calls; this changelog ++ session transcript ARE the as-executed record for these mutations). + +**Profile registration (operator-authorised credential one-shot).** Registered the +`vr1-dc0-region` maas CLI profile on the dc0 rack `vvr1-dc0` (172.31.0.2) pointing at +the in-DC regional API `http://10.12.8.6:5240/MAAS/` (node hot-kid). SEC-safe: key read +from `~/vr1-dc0-creds/maas-region-api-key.txt` and piped to `maas login ... -` via +stdin (never argv/ps/history/context). VERIFIED: profile resolves to region-controller +`hot-kid` and returns provider `10.12.4.0/22` gw `10.12.4.1`. Closes F3 (rack now +carries openstack + a DC-regional maas profile). Revert: `maas logout vr1-dc0-region` +on the rack. + +**Permission rule (settings.local.json, gitignored).** Added 4 tightly-scoped allow +rules for the nested-ssh phase-04/phase-05 staged-script invocations on 172.31.0.2 +(the auto-mode classifier walled the mutation despite a broad `ssh *`; targeted rules +clear it -- the project's known pattern). NOT a broad ssh grant. Revert: remove the 4 +`phase-04-*`/`phase-05-*` entries from `.claude/settings.local.json`. + +**phase-04 network-create (live cloud mutation).** Ran +`MAAS_PROFILE=vr1-dc0-region phase-04-network-create.sh` on the rack. Created: +- network `provider-ext` id `bc284f47-477b-40d9-90a9-25106981e5e8` (external, flat, + physnet1, shared=false, tag role=provider); +- subnet `provider-ext-fip` id `7851c88e-e921-442e-990e-7084e73a6451` (cidr + 10.12.4.0/22, gw 10.12.4.1, no-dhcp, FIP pool 10.12.5.0-10.12.7.254). +POST verify: **phase-04 EXIT GATE PASS**. Revert (throwaway checkpoint anyway): +`openstack subnet delete provider-ext-fip; openstack network delete provider-ext`. + +**Measured, logged NOT chased:** `glance-simplestreams-sync/0` is `unknown`/idle -- a +service NOTHING in the checkpoint scope (networks + 1 LB + 1 zone + wrap gates) +consumes; the amphora pipeline seeds its own base. Dropped from Task #2 scope per +advisor; recorded here as a finding, not a task. + +**Correction to F3 (reaches the sweep too):** F3 claimed the phase-05 octavia path also +needs maas -- FALSE (grep of scripts/phase-05-*.sh shows no maas dependency). The fix +was contained to the two phase-04 network scripts. + +--- + +## Item 4 -- G18 (Octavia lb-mgmt IPAM apex recording) RULED (GA-R5, option b) + +**What.** Gate G18 CLOSED 2026-08-08. Operator ruled **option (b)**: the charm-created +Octavia `lb-mgmt-net` is recorded as deliberately charm-owned and OUT of apex scope +(structural note, not a concrete prefix row); the separate D-139 apex GUA `lb-mgmt` /64 +is kept `reserved`. Recorded in `docs/CURRENT-STATE.md` (G18 gate row -> CLOSED, primary +record) + annotations on the D-101/R8 note and D-139 in `docs/design-decisions.md`. NO new +D-number (annotates existing rulings). Prep package (background agent, Task #6-style): +`docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md`. + +**Why.** Operator sequenced "rule G18 first, then fire [octavia]". `configure-resources` +creates the lb-mgmt network; R8 (D-101 note) already ruled ownership/family/charm-generated +source, so G18's only live question was apex-recording. The lb-mgmt prefix is a v6-ULA +`fc00::/64` (regenerates per deploy) -- OUTSIDE the 10.12->10.13 v4 re-IP entirely. Option (b) +is R8-aligned, D-141-compliant, and natively portable to the rebuild. + +**OWED post-`configure-resources` (read-only):** capture actual `fc00::/64` (`openstack +subnet list --tags charm-octavia`); router `external_gateway_info` (isolation, R8 left +unasserted); `o-hm0` MTU match (LP#2018998). + +**Revert.** Re-open the G18 gate row in CURRENT-STATE (CLOSED -> OPEN) and remove the two +design-decisions annotations; the prep package is analysis-only. + +--- + +## Item 5 -- Designate decision: REAL D-106/D-117 Stage-7 activation (operator choice) + +**What.** Operator chose the **real D-106/D-117 Stage-7 Designate activation** for the dc0 +checkpoint (not a throwaway placeholder zone): D-117 zone labels + the os-public-hostname / +Vault FQDN-SAN-cert prerequisites, then nameservers + zone with A/AAAA. Task #4 will follow +D-106's bootstrap order. Rationale (operator prerogative): validate the real Stage-7 DNS +procedure/tooling on dc0 so it transfers to the 10.13 rebuild (minimize-delta-to-Roosevelt), +even though dc0 is throwaway and currently IP-only. + +**Scope note (surfaced, not yet executed):** this pulls the full D-106 bootstrap forward -- +os-public-hostname on the API charm(s) flips IP-only -> FQDN + re-issues FQDN-SAN certs. Each +step will be gated. Pre-check MEASURED: designate/0-2 blocked "nameservers must be set", +nameservers config EMPTY, designate-bind/0 active; `designateclient` absent on the rack. + +**Revert.** N/A (decision record; execution reverts per its own steps when taken). diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 900c801..681006a 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2605,6 +2605,18 @@ `fc00::/` ULA on o-hm0 and is VR0-era, which independently confirms the octavia charm's default lb-mgmt-subnet is an IPv6 ULA. The as-built already assumed what R8 ruled. +**G18 RULED 2026-08-08 (GA-R5) -- annotates this R8 note; see `docs/CURRENT-STATE.md` G18 +row for the primary record.** The apex-recording question R8 left open (presented separately +as gate G18) is now ruled **option (b)**: the charm-created `lb-mgmt-net` is recorded as +deliberately charm-owned and OUT of apex scope (the apex carries a structural note, not a +concrete prefix row the deploy consumes) -- D-141-compliant, since D-141 governs CONSUMED +allocations and the charm-generated ULA (regenerates per deploy) is not one. R8's ownership / +family / charm-generated-prefix ruling is NOT reopened. The SEPARATE D-139 apex GUA `lb-mgmt` +/64 is kept `reserved` (a distinct MAAS-underlay object with no charm consumer -- see the +D-139 annotation). Operator's exact selection: "B: record out of apex scope + keep D-139 /64 +reserved (Recommended)". No new D-number. Prep + governing-decision reconciliation: +`docs/audit/g18-lb-mgmt-ipam-ruling-prep-20260808.md`. + **What IS owed, all mechanical, no ruling required:** propagate the ratified v6 carve into `scripts/lib-net.sh` (a v6 arm per DC, keyed the same way the v4 `PLANE_CIDRS` arms are), and carve the twelve plane prefixes into MAAS as subnets on their existing fabrics. Both @@ -7245,6 +7257,17 @@ ruling B sets the ADDRESSING MODEL. A is independent of B and would stand if B were reversed. +**ANNOTATION 2026-08-08 (G18 ruling cross-ref -- see `docs/CURRENT-STATE.md` G18 row + the +D-101/R8 note):** ruling B carved an apex GUA `lb-mgmt` /64 (dc0 `2602:f3e2:f02:80::/64`) as +a NEW MAAS-underlay plane (execution step 5). MEASURED: octavia binds to NO `lb-mgmt` space +(bundle.yaml octavia bindings; network-space-binding-reference), so this apex GUA plane has +NO charm consumer and is a DISTINCT object from the charm's Neutron `lb-mgmt-net` (the ULA +`fc00::/64` the octavia charm creates and owns per R8). Per the G18 ruling (option b), this +D-139 apex GUA `lb-mgmt` /64 is kept **`reserved`** -- an architectural underlay allocation +with intent recorded and no live consumer (D-141 `reserved`-until-consumable discipline), +explicitly NOT the charm's management network. A future session must not conflate the two or +"fix" the empty plane by pointing octavia at it (that would reopen R8). + Raised by a live measurement session that overturned the recorded root cause of the IPv4-only-container problem (see "What forced this" below). Admitted under GA-R3's A1 test: a Roosevelt build session would grep this before carving a plane, and Roosevelt's