# phase-00 MAAS stand-up (D-058) -- notes

`scripts/phase-00-maas-standup.sh` brings MAAS to the D-058 plane topology
idempotently. **Dry-run is the audit** (default): it resolves live ids BY
CIDR/name (PATTERN-1) and prints the plan, changing nothing. `--apply` executes.

## Behavior per resource
- present and correct -> **SKIP**
- absent -> **CREATE** (fabric / VLAN / subnet / space / gateway / managed / dns / API-VIP reserve)
- present but bound to the wrong plane or wrong VID -> **DRIFT** (reported, never touched)

A re-CIDR is destructive (MAAS cannot change a subnet CIDR in place), so it is
**out of scope by design**: the drift scan reports it as MIGRATE-NEEDED and the
script refuses to build onto a CIDR the wrong plane occupies. Verified idempotent
on `--apply` (zero mutations against an already-correct cloud).

## D-058 target (what it stands up)
provider-public 10.12.4.0/22 (untagged, gw .4.1) | provider-vip 10.12.8.0/22
(VID 104 on the provider fabric, gw .8.1, VIP band .8.2-.100) | metal-admin
10.12.12.0/22 (untagged, gw .12.1, VIP band .12.2-.100) | metal-internal
10.12.16.0/22 (VID 103 on the metal fabric, VIP band .16.2-.100) | data-tenant
10.12.20.0/22 | storage 10.12.32.0/22 | replication 10.12.36.0/22. Untagged base
planes are created first so their tagged siblings can ride the same fabric
(provider-public->provider-vip, metal-admin->metal-internal).

## Scope boundary
- THIS script owns topology + the three API-VIP reserve bands (the bundle deploy
  depends on those reserves existing).
- `phase-00-maas-carve.sh` keeps the FIP pool, mgmt reserves, and stale-range
  cleanup. (Its D-058 CIDR update is the next pass.)
- It never deletes anything.

## Relationship to provider-vip-standup.sh
This generalizes that script from one plane to the whole topology; provider-vip is
now just one row of the table. `provider-vip-standup.sh` remains the targeted
single-plane tool (add provider-vip to an already-D-058 cloud). Both source
`lib-net.sh`; no conflict.

## Tests
`tests/phase-00-maas-standup/` -- fake `maas` + real jq, fixtures generated by
`make_fixtures.py`. Four scenarios, ALL PASS: fresh MAAS (full create plan),
D-058 done (all SKIP / zero WOULD), D-052 current (the three migrating planes
drift + refuse), wrong-VID (vid drift). Run: `bash tests/phase-00-maas-standup/run-tests.sh`.

## The current-cloud gap (next deliverable)
The live cloud is D-052/053, so this stand-up will report metal-admin (.8),
metal-internal (.12), data-tenant (.16) as DRIFT -- those CIDRs are reassigned by
D-058. The destructive cutover (release/teardown so subnets have no links, delete
the old subnets in collision-safe order, then `--apply` to build the new scheme)
is a **separate gated step**, not this script. Sequence: teardown -> delete old
subnets -> `phase-00-maas-standup.sh --apply` -> `phase-00-maas-carve.sh`
(D-058) -> jumphost bridge re-IP (D-058 ordering trap) -> deploy.