CANARY RE-COMMISSION -- vr1-dc0-storage-01, 2026-07-29
======================================================
Operator approval: "Commission storage-01 as the canary". Run from voffice1. This is the
empirical close of R1 precondition 3, which the D-121 amendment said must be verified
BEFORE the apply and which had until now only been answered from the API's own help text.

MACHINE: sysid kghggm, MAAS hostname `first-oryx` (MAAS renames at enlistment -- matched
by PINNED BOOT MAC 52:54:00:5f:8d:42, never by name).

COMMAND (skip_storage deliberately UNSET so storage IS re-scanned):
    maas admin machine commission kghggm skip_networking=1

TIMELINE: Commissioning -> Ready in ~200s. No timeout, no SERVFAIL. (For contrast, the
2026-07-21 pre-D-131 failures were seven consecutive 30-minute timeouts.)

RESULT -- the full before/after diff of status, power, block devices, interfaces, MACs and
links is EXACTLY ONE HUNK:

    "blockdevices": [ ["vda", 590558003200],
   +                  ["vdb", 536870912000]  ]

  links   BEFORE/AFTER : 12 / 12
  MACs identical       : True
  links identical      : True

536870912000 bytes = 500 GiB exactly -- the volume R1's apply created.

WHAT THIS SETTLES. `skip_networking=1` preserves the network configuration EXACTLY: all 12
static links survive with their addresses, modes, subnets and per-interface MACs unchanged,
including the D-134 octet .150 mirrored across all six planes in both families (the v6 host
part ::150 is the 2026-07-27 D-136 mirror ruling, visible here in live data). Meanwhile
storage IS re-scanned and the new device enters MAAS's inventory, which is the entire point.

Precondition 3 is now closed by MEASUREMENT rather than by reading the API help. The
amendment's concern was legitimate -- the DEFAULT commissioning path does reconfigure
networking -- and the vendor's own control is sufficient.

NOT YET DONE: the other three dc0 storage nodes (storage-02/03/04), and all of dc1.