|
DHCP handover EXECUTED: dc0 metal-admin now served by the DC-local region
Ruled order, region identity proven first. Office1 vlan update 4 0 dhcp_on=false -> read back False; verified STOPPED BY PROCESS (pgrep -c dhcpd = 0 on the rack, because MAAS self-report is not evidence -- the 2026-07-20 Temporal incident class); new region vlan update 0 0 dhcp_on=true primary_rack=c3aqh8 -> read back True on fabric-0 / space metal-admin; verified RUNNING BY PROCESS on hot-kid with the rack re-checked at 0. Exactly one DHCP server on the segment. All 10 machines Ready and powered off throughout. Recorded so it is not later read as a fault: the new region also starts dhcpd6 where the Office1 rack ran v4 only. Its v6 metal-admin subnet has NO dynamic range -- only rfc-4291-2.6.1 and assigned-ip/reserved, same as the old region -- so it has nothing to hand out and nodes keep their ruled statics. The permission wall was a rule that FAILED TO MATCH, not a classifier fault. Existing ask rules pin the double-quote form while the commands used single quotes, and pin the maas admin profile while the new region needs maas vr1-dc0-region. Operator-approved ask rules added to settings.local.json (gitignored; committed team policy unchanged), profile-agnostic so both regions match, plus read-only pgrep/ps allow rules. The first rule shape I proposed pinned maas admin and would have matched step 1 while silently missing step 3 -- stalling the cutover at exactly the two-servers boundary. Capture docs/audit/dc0-dhcp-handover-20260730.txt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/audit/dc0-dhcp-handover-20260730.txt 0 → 100644 |
|---|
| docs/changelog-20260730-dc0-region-migration.md |
|---|