Add “enroll” state to the state machine¶
https://blueprints.launchpad.net/ironic/+spec/enroll-node-state
This blueprint introduces a new state called enroll
, which we previously
agreed to introduce in the new state machine spec.
Problem description¶
Currently nodes on creation are put into available
state, which is designed
as a replacement for NOSTATE
. Such nodes will instantly be available
to Nova for deployment, provided they have all the required properties.
However, the new state machine lets the operator perform inspection on a node
and zapping of a node. The state machine allows for them to be done before a
node reaches the available
state.
Even worse, the cleaning feature introduced in Kilo cycle should also
happen before a node becomes available
.
Proposed change¶
Add a new state
enroll
, from which a node can transition into themanageable
state by an action calledmanage
.manage
transition will cause power and management interfaces to be validated on the node. Also an attempt will be made to get the power state on a node to actually verify the supplied power credentials.On success, the node will go to the
manageable
state. On failure, it will go back to theenroll
state andlast_error
will be set.Disable the sync_power_state for nodes in the
enroll
state, as nodes in this state are not expected to have valid power credentials.Introduce a new API microversion, making newly created nodes appear in the
enroll
state instead of theavailable
state.After that the client-server interaction will be the following:
new client (with new API version) + new server: nodes appear in the
enroll
state.new client + old server: client gets a response from the server stating that node is in
available
(ornone
) state. Client issues a warning to the user.old client (or new client with old API version) + new server: due to versioning the node will appear in
available
(ornone
) state.
Document that we are going to make a breaking move to the
enroll
state by default.Update DevStack gate to explicitly request the new microversion and fix the tests.
Release a new version of
ironicclient
defaulting to this new microversion. Clearly document this breaking change in upgrade notes.
Alternatives¶
We can ask people to manually move nodes to the manageable
state before
inspection or zapping. We also won’t validate power and management interfaces.
Data model impact¶
None
State Machine Impact¶
enroll
becomes a valid node state with transitions to:verifying
viamanage
action
verifying
becomes a valid transient node state with transitions to:manageable
ondone
enroll
onfail
andlast_error
will be set.
REST API impact¶
Add new API microversion. When it is declared by client, node creation API should default to creating nodes in the
enroll
state.
Client (CLI) impact¶
New release of client will be issued defaulting to the new microversion (and breaking many flows).
RPC API impact¶
None
Driver API impact¶
None
Nova driver impact¶
Double check that Nova driver won’t use nodes in
enroll
stateSync
nova/virt/ironic/ironic_states.py
for the sake of consistency
No functionality impact expected.
Security impact¶
None expected
Other end user impact¶
With the new microversion, nodes will appear in the enroll
state. Two more
steps should be taken to make them available for deploy: manage
and
provide
. Cleaning will happen, if enabled.
Scalability impact¶
None
Performance Impact¶
None
Other deployer impact¶
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Dmitry Tantsur, IRC: dtantsur, LP: divius
- Other contributors:
None
Work Items¶
Create new states and transitions
Introduce new microversion with node defaulting to
enroll
on creationMake sure our tests do not break (fix devstack etc)
Default ironicclient to the new microversion
Dependencies¶
None
Testing¶
Tempest tests should be modified to test
enroll
state.
Upgrades and Backwards Compatibility¶
Change is backwards compatible, while it’s not the default in ironicclient.
Once new microversion is the default in ironicclient, it will break existing flows, when explicit microversion is not in use.
Documentation Impact¶
Working with the new state and the transition should be documented
Upgrade notes should be updated