Post-deployment NetBox VIP imports (queued from workstream 2)

Status: Queued. To be imported after successful cloud deployment + validation, once netbox/ipv4-prefixes-import.py engineer review unblocks the Provider /22 prefix import.

Background: Per D-010 (NetBox-upstream policy), IPAM entries should exist in NetBox before being written into IaC. For v1 testcloud, this rule was relaxed under workstream 2 (2026-05-22) to avoid blocking the rebuild on the engineer review. VIPs were written into bundle.yaml directly. This document captures the corresponding NetBox writes that need to happen post-deploy.

Scope: v1 only (IPv4). v2 IPv6 VIPs are out of scope.

Provider prefix (parent — gating)

Before any IPAddress entries can be created, the parent prefix must exist:

Created by: netbox/ipv4-prefixes-import.py (per D-010, gated on engineer review).

VIP IPAddress entries

All entries under prefix 10.12.4.0/22, tenant scope = VR0 DC0 Omega Cloud (or appropriate testcloud tenant convention).

Notes:

• Mask is /22 (the parent prefix mask), not /32 — NetBox convention for endpoint IP addresses within a prefix.
• The Reserved slots at .225 and .227 document v2 intent without consuming active allocations. When v2 work brings ceph-radosgw HA and Designate online, those entries' Status flips Reserved → Active and the bundle's # v2-deferred: markers are uncommented.
• nova-cloud-controller charm → DNS short name nova (catalog service name, not charm name).
• openstack-dashboard charm → DNS short name horizon (project name).
• neutron-api charm → DNS short name neutron.

FIP pool — for completeness (not part of workstream 2)

Per D-003, the Provider /22 also carries the Neutron FIP pool. These are NOT individual IPAddress entries; they're modeled as an IP Range under the prefix:

Neutron allocation_pools for the provider subnet MUST exclude .224–.254 — this is enforced in runbooks/06-tenant-setup.md (or wherever the provider subnet is created).

Execution path (when unblocked)

1. Confirm engineer review of netbox/ipv4-prefixes-import.py has signed off.
2. Run netbox/ipv4-prefixes-import.py — creates the Provider /22 prefix + FIP IP Range + API VIP IP Range.
3. Add the 13 IPAddress entries from the table above. Two paths:
   • Web UI: Per-entry manual creation. Tedious but reviewable.
   • API/script: Extend ipv4-prefixes-import.py with a VIP-addresses section, OR write a separate netbox/ipv4-vips-import.py that reads this document (or a YAML/CSV companion). Idempotent (skip-if-exists).
4. Sanity check: NetBox prefix view of 10.12.4.0/22 shows all 13 entries.
5. Cross-check: every active VIP in bundle.yaml has a matching Active entry in NetBox; the Reserved entries at .225 and .227 have no corresponding bundle entries (v2-deferred).

Change log

| 2026-05-27 | Designate VIP at .227 flipped Active → Reserved per D-019 (Designate deferred to v2). Active count: 11; Reserved count: 2. | D-019 |

Management-plane reservations (MAAS-side; draft <- live, queued for NetBox)

Status: Queued / draft. Observed live in MAAS during the 2026-06-11 rebuild; recorded here draft <- live (live MAAS state is truth; this doc is the reconciliation target). NOT yet written to NetBox -- D-010 (NetBox is unmutated until the IPAM design is confirmed). Purpose-pending: the ranges were reserved on the mgmt plane but their per-IP role is not yet assigned.

Two contiguous reservation ranges on the provider + metal segments (cf. D-003 -- the provider network carries ext_net + API VIPs on one L2; D-010 -- NetBox-upstream policy):

To reconcile before NetBox import: confirm each range's intended role (host mgmt, OOB, spare pool, etc.) and the metal-segment prefix, then create the matching NetBox IPRange/IPAddress entries with the resolved role + DNS convention. Do NOT mutate NetBox until the role assignment is confirmed (D-010). The /22-mask convention (not /32) applies, as for the VIP entries above.