Node-naming canary: a MAAS rename alone is cosmetic-only
Operator asked for the juju status Inst id values to become role-based.

CORRECTION to an earlier claim this session: that column shows the MAAS
HOSTNAME, not the system_id. My first reading came from the JSON instance-id
field (677cta) and was wrong -- the displayed value is the hostname and it IS
renameable.

Canary: civil-bug resolved BY PINNED BOOT MAC (52:54:00:2b:ed:ab) to the ruled
vr1-dc0-storage-04, then renamed.

MEASURED: MAAS ACCEPTED the rename on a Deployed machine (fqdn
vr1-dc0-storage-04.maas), but juju status still shows civil-bug AND the running
OS still answers civil-bug (hostname and hostnamectl --static). MAAS's record
moves and nothing else does -- juju captured the name at provisioning, and the
OS hostname is applied by cloud-init at DEPLOY time.

CONSEQUENCE: renaming the other eight buys nothing where the operator is looking
and leaves a three-way divergence. Nothing functional rides on it -- the bundle
places by TAG and every gate resolves by PINNED BOOT MAC.

THE CLEAN POINT IS ENLISTMENT: folds into the DC1 standup as a DoD item (set the
ruled hostname BEFORE commissioning so MAAS, the OS and the ruled name agree),
and reaches DC0 at its next node redeploy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
1 parent 33f3a5e commit 0d964db99eff2181ec2afe7345c67199f90d77cb
@JANeumatrix JANeumatrix authored 13 hours ago
Showing 1 changed file
View
docs/CURRENT-STATE.md