Add "enroll" state to the state machine
This spec describes introduction of ``enroll`` state, which we previously agreed to introduce in the new state machine spec. Spec for blueprint enroll-node-state Change-Id: I2b39f265e864c58ec70a1a06efcc65e5d5d5b115
This commit is contained in:
parent
e4665a55ab
commit
983cf4ab29
@ -82,8 +82,8 @@ Descriptions of the states for the current state machine can be found `here
|
||||
|
||||
New state machine::
|
||||
|
||||
ENROLL -----------> [VALIDAT*/MANAGEABLE]
|
||||
R:validate |
|
||||
ENROLL -----------> [VERIFY*/MANAGEABLE]
|
||||
R:manage |
|
||||
v
|
||||
+------>MANAGEABLE<--------+
|
||||
| + + ^ | |
|
||||
@ -149,10 +149,10 @@ ENROLL
|
||||
ENROLL, the only thing Ironic knows about it is that it exists, and
|
||||
Ironic cannot take any further action by itself. Once a node has
|
||||
its drivers and the required information for each driver in
|
||||
node.properties, the node can be transitioned to VALIDATING via the
|
||||
validate API call
|
||||
node.properties, the node can be transitioned to VERIFYING via the
|
||||
manage API call
|
||||
|
||||
VALIDATING
|
||||
VERIFYING
|
||||
Ironic will validate that it can manage the node with the drivers
|
||||
and the credentials it has been assigned. For drivers that manage
|
||||
power state of the node, this must involve actually going out and
|
||||
@ -293,7 +293,7 @@ the state machine:
|
||||
+-----------+--------------+--------------------------+-----------+
|
||||
| Verb | Initial State| Intermediate States | End State |
|
||||
+===========+==============+==========================+===========+
|
||||
| validate | ENROLL | VALIDATING -> VALIDATED | MANAGEABLE|
|
||||
| manage | ENROLL | VERIFYING -> VERIFIED | MANAGEABLE|
|
||||
+-----------+--------------+--------------------------+-----------+
|
||||
| zap | MANAGEABLE | ZAPPING -> ZAPPED | MANAGEABLE|
|
||||
+-----------+--------------+--------------------------+-----------+
|
||||
@ -374,7 +374,7 @@ Other deployer impact
|
||||
|
||||
Nodes will not automatically transition from ENROLL to MANAGEABLE.
|
||||
Deployers must assign drivers and add credentials to the node and then
|
||||
call the validate API before Ironic can manage the node.
|
||||
call the manage API before Ironic can manage the node.
|
||||
|
||||
Nodes will not automatically transition from MANAGEABLE to AVAILABLE,
|
||||
deployers will need to do that via the API before nodes can be scheduled.
|
||||
|
208
specs/liberty/enroll-node-state.rst
Normal file
208
specs/liberty/enroll-node-state.rst
Normal file
@ -0,0 +1,208 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================================================
|
||||
Add "enroll" state to the state machine
|
||||
==================================================
|
||||
|
||||
https://blueprints.launchpad.net/ironic/+spec/enroll-node-state
|
||||
|
||||
This blueprint describes introduction of ``enroll`` state, 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, `new state machine`_ accounts for at least inspection and ready state
|
||||
features like zapping, which should be done before node even gets
|
||||
into ``available`` state.
|
||||
|
||||
Even worse, cleaning feature introduced in Kilo cycle should also
|
||||
happen before node becomes ``available``.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* Add new state ``enroll``, from which node can transition into
|
||||
``manageable`` state by action called ``manage``.
|
||||
|
||||
* ``manage`` transition will cause power and management interfaces to be
|
||||
validated on node. Also an attempt will be made to get power state on a node
|
||||
to actually verify the supplied power credentials.
|
||||
|
||||
On success, node will get to ``manageable`` state. On
|
||||
failure, it will get back to ``enroll`` and ``last_error`` will be set.
|
||||
|
||||
* Disable sync_power_state for nodes in ``enroll`` state, as nodes in this
|
||||
state are not expected to have valid power credentials.
|
||||
|
||||
* Introduce new API microversion, making newly created nodes appear in
|
||||
``enroll`` state instead of ``available``.
|
||||
|
||||
After that client-server interaction will be the following:
|
||||
|
||||
- new client (with new API version) + new server: nodes appear
|
||||
in ``enroll`` state.
|
||||
|
||||
- new client + old server: client gets response from the server stating that
|
||||
node is in ``available`` (or ``none``) state. Client issues a warning to a
|
||||
user.
|
||||
|
||||
- old client (or new client with old API version) + new server:
|
||||
due to versioning node will appear in ``available`` (or ``none``) state.
|
||||
|
||||
* Document that we are going to make a breaking move to ``enroll`` state by
|
||||
default.
|
||||
|
||||
* Update DevStack gate to explicitly request the new microversion and fix the
|
||||
tests.
|
||||
|
||||
* Release 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 ``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`` via ``manage`` action
|
||||
|
||||
* ``verifying`` becomes a valid transient node state with transitions to:
|
||||
|
||||
* ``manageable`` on ``done``
|
||||
|
||||
* ``enroll`` on ``fail``.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
* Add new API microversion. When it is declared by client, node creation API
|
||||
should default to creating nodes in ``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`` state
|
||||
|
||||
* Sync ``nova/virt/ironic/ironic_states.py`` for the sake of consistency
|
||||
|
||||
No functionality impact expected.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None expected
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
With new microversion nodes will appear in ``enroll`` state. 2 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
|
||||
---------------------
|
||||
|
||||
See `Upgrades and Backwards Compatibility`_.
|
||||
|
||||
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 creation
|
||||
|
||||
* Make 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 new state and transition should be documented
|
||||
|
||||
* Upgrade notes should be updated
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. _new state machine: http://specs.openstack.org/openstack/ironic-specs/specs/kilo/new-ironic-state-machine.html
|
Loading…
Reference in New Issue
Block a user