# 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: | Prefix | Site | Role | Status | |---|---|---|---| | `10.12.4.0/22` | VR0 DC0 | provider | Active | 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). | IP | Status | DNS name | Description | |---|---|---|---| | `10.12.4.224/22` | Active | `barbican.omega.dc0.vr0.cloud.neumatrix.local` | barbican API VIP — Charmed OpenStack hacluster | | `10.12.4.225/22` | Reserved | — | RESERVED for ceph-radosgw HA VIP in v2 (workstream-2 decision; ceph-radosgw HA deferred to v2) | | `10.12.4.226/22` | Active | `cinder.omega.dc0.vr0.cloud.neumatrix.local` | cinder API VIP — Charmed OpenStack hacluster | | `10.12.4.227/22` | Reserved | — | RESERVED for designate VIP in v2 (per D-019; Designate deferred to v2) | | `10.12.4.228/22` | Active | `glance.omega.dc0.vr0.cloud.neumatrix.local` | glance API VIP — Charmed OpenStack hacluster | | `10.12.4.229/22` | Active | `keystone.omega.dc0.vr0.cloud.neumatrix.local` | keystone API VIP — Charmed OpenStack hacluster | | `10.12.4.230/22` | Active | `magnum.omega.dc0.vr0.cloud.neumatrix.local` | magnum API VIP — Charmed OpenStack hacluster | | `10.12.4.231/22` | Active | `neutron.omega.dc0.vr0.cloud.neumatrix.local` | neutron-api API VIP — Charmed OpenStack hacluster | | `10.12.4.232/22` | Active | `nova.omega.dc0.vr0.cloud.neumatrix.local` | nova-cloud-controller API VIP — Charmed OpenStack hacluster | | `10.12.4.233/22` | Active | `octavia.omega.dc0.vr0.cloud.neumatrix.local` | octavia API VIP — Charmed OpenStack hacluster | | `10.12.4.234/22` | Active | `horizon.omega.dc0.vr0.cloud.neumatrix.local` | openstack-dashboard (Horizon) VIP — Charmed OpenStack hacluster | | `10.12.4.235/22` | Active | `placement.omega.dc0.vr0.cloud.neumatrix.local` | placement API VIP — Charmed OpenStack hacluster | | `10.12.4.236/22` | Active | `vault.omega.dc0.vr0.cloud.neumatrix.local` | vault VIP — Charmed Vault hacluster (D-006) | **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: | Range | Purpose | |---|---| | `10.12.4.10 – 10.12.4.223` | Neutron FIP pool (created by `ipv4-prefixes-import.py`) | | `10.12.4.224 – 10.12.4.254` | API VIP pool (the 13 entries above + future) | 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 | Date | Change | Reference | |---|---|---| | 2026-05-22 | Document created. 12 active VIP allocations queued + 1 v2-reserved slot. | Workstream 2 — VIP allocation + hacluster activation | | 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): | Range | Segment | Status | Purpose | |---|---|---|---| | `10.12.4.101` - `10.12.4.110` | provider `10.12.4.0/22` | Reserved (MAAS) | mgmt-plane, role TBD -- reconcile before NetBox write | | `10.12.8.101` - `10.12.8.110` | metal/internal (`10.12.8.x`; prefix TBC) | Reserved (MAAS) | mgmt-plane, role TBD -- reconcile before NetBox write | **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.