|
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 |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|