Skip to content

Admit a node to service only after it passes commissioning checks (READY state) #16041

Open

Description

@mrveiss

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 READY state reached from ENROLLING only 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 ERROR with the failing check named — never silently ONLINE.
  • Only a READY/ONLINE node 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

  • READY exists between ENROLLING and ONLINE, 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/ONLINE without a re-enrollment cycle
  • Test: a node failing an admission check never becomes eligible for deployment

Implementation Order

Wave: 2
Depends on: none

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions