Fork: 0
OpenStack / openstack-caracal-ipv4
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-ipv4 / docs / phase-00-maas-standup-notes.md
@JANeumatrix JANeumatrix 1 day ago 2 KB MAAS script updates
Raw Blame History

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

Single MAAS-address authority (D-058 consolidation)

  • THIS script owns topology AND every reserved range: the API-VIP bands, the Neutron FIP pool (10.12.5.0-.7.254 on provider-public), and the mgmt reserves.
  • phase-00-maas-carve.sh is RETIRED -- its reserves are folded in here, and its gated stale-range delete is subsumed by the teardown + re-CIDR step.
  • 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.