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:

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).
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).
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`)

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.
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.
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.