Repository navigation
Admit a node to service only after it passes commissioning checks (READY state) #16041
Description
Parent: SLM method-adoption umbrella (#16028). Source: MAAS machine life-cycle.
Method
A node becomes eligible for work by passing checks, not by finishing enrollment. MAAS runs
New → Commissioning → Ready → Deployed, where Commissioning boots the machine, probes its
hardware, applies baseline config and runs tests — built-in ones plus operator-uploaded scripts that
act as quality gates. Only a machine that passes reaches Ready, and only a Ready machine has the
complete inventory MAAS needs to schedule onto it. A failure lands in Failed, not in service.
Already-exists audit
models/database.py:35-46:
PENDING → ENROLLING → ONLINE → DEGRADED | OFFLINE | ERROR | MAINTENANCE | DECOMMISSIONED
There is no state between ENROLLING and ONLINE. A node becomes ONLINE by completing enrollment;
nothing asserts it is fit to carry a role first.
The data a gate would need is already collected — the agent ships slm/agent/role_detector.py,
slm/agent/port_scanner.py and slm/agent/health_collector.py, and api/discovery.py exists. The
inventory is gathered; it just isn't a precondition for anything.
MAINTENANCE already exists in the enum, which is useful for #16036 but is a different axis — that
is "temporarily withdrawn", not "not yet admitted".
Change
- Add a
READYstate reached fromENROLLINGonly after declared admission checks pass. - Admission checks are declarative and extensible, following MAAS's split: built-in probes plus
operator-supplied checks. - A failed check lands the node in
ERRORwith the failing check named — never silently ONLINE. - Only a
READY/ONLINEnode is eligible for role assignment and deployment.
Relationship to #16030
Same principle at a different scope: #16030 makes a role declare when it is inapplicable to a node;
this makes a node prove it is fit for roles at all. Both must surface the reason rather than the
absence — an unexplained skip and an unexplained non-admission are equally useless to an operator.
Acceptance criteria
-
READYexists betweenENROLLINGandONLINE, and the transition is gated on admission checks - Admission checks are declarative; operators can add one without changing the state machine
- A failed check names itself in the node's error state
- Role assignment and deployment reject a node that has not reached
READY - Existing nodes migrate to
READY/ONLINEwithout a re-enrollment cycle - Test: a node failing an admission check never becomes eligible for deployment
Implementation Order
Wave: 2
Depends on: none
Activity