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

