Add “enroll” state to the state machine¶
This blueprint introduces a new state called
enroll, which we previously
agreed to introduce in the new state machine spec.
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
Even worse, the cleaning feature introduced in Kilo cycle should also
happen before a node becomes
Add a new state
enroll, from which a node can transition into the
manageablestate by an action called
managetransition 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
manageablestate. On failure, it will go back to the
last_errorwill be set.
Disable the sync_power_state for nodes in the
enrollstate, 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
enrollstate instead of the
After that the client-server interaction will be the following:
new client (with new API version) + new server: nodes appear in the
new client + old server: client gets a response from the server stating that node is in
none) 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
Document that we are going to make a breaking move to the
enrollstate by default.
Update DevStack gate to explicitly request the new microversion and fix the tests.
Release a new version of
ironicclientdefaulting to this new microversion. Clearly document this breaking change in upgrade notes.
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¶
State Machine Impact¶
enrollbecomes a valid node state with transitions to:
verifyingbecomes a valid transient node state with transitions to:
last_errorwill 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
Client (CLI) impact¶
New release of client will be issued defaulting to the new microversion (and breaking many flows).
RPC API impact¶
Driver API impact¶
Nova driver impact¶
Double check that Nova driver won’t use nodes in
nova/virt/ironic/ironic_states.pyfor the sake of consistency
No functionality impact 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:
provide. Cleaning will happen, if enabled.
Other deployer impact¶
- Primary assignee:
Dmitry Tantsur, IRC: dtantsur, LP: divius
- Other contributors:
Create new states and transitions
Introduce new microversion with node defaulting to
Make sure our tests do not break (fix devstack etc)
Default ironicclient to the new microversion
Tempest tests should be modified to test
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.
Working with the new state and the transition should be documented
Upgrade notes should be updated