Remove outdated API version information from the enrollment docs
Change-Id: I846ce901137bede05543a40e4d91930c4fddad41 Closes-Bug: #1753435
This commit is contained in:
parent
abbd859b76
commit
cc9fa85260
@ -81,15 +81,9 @@ affected, since the initial provision state is still ``available``.
|
|||||||
However, using API version 1.11 or above may break existing automation tooling
|
However, using API version 1.11 or above may break existing automation tooling
|
||||||
with respect to node creation.
|
with respect to node creation.
|
||||||
|
|
||||||
The default API version used by (the most recent) python-ironicclient is 1.9,
|
The ``openstack baremetal`` command line tool tries to negotiate the most
|
||||||
but it may change in the future and should not be relied on.
|
recent supported version, which in virtually all cases will be newer than
|
||||||
|
1.11.
|
||||||
In the examples below we will use version 1.11 of the Bare metal API.
|
|
||||||
This gives us the following advantages:
|
|
||||||
|
|
||||||
* Explicit power credentials validation before leaving the ``enroll`` state.
|
|
||||||
* Running node cleaning before entering the ``available`` state.
|
|
||||||
* Not exposing half-configured nodes to the scheduler.
|
|
||||||
|
|
||||||
To set the API version for all commands, you can set the environment variable
|
To set the API version for all commands, you can set the environment variable
|
||||||
``IRONIC_API_VERSION``. For the OpenStackClient baremetal plugin, set
|
``IRONIC_API_VERSION``. For the OpenStackClient baremetal plugin, set
|
||||||
@ -118,7 +112,6 @@ and may be combined if desired.
|
|||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
$ export OS_BAREMETAL_API_VERSION=1.11
|
|
||||||
$ baremetal node create --driver ipmi
|
$ baremetal node create --driver ipmi
|
||||||
+--------------+--------------------------------------+
|
+--------------+--------------------------------------+
|
||||||
| Property | Value |
|
| Property | Value |
|
||||||
@ -423,12 +416,13 @@ Validating node information
|
|||||||
Making node available for deployment
|
Making node available for deployment
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
In order for nodes to be available for deploying workloads on them, nodes
|
In order for nodes to be available for deploying workloads on them, nodes must
|
||||||
must be in the ``available`` provision state. To do this, nodes
|
be in the ``available`` provision state. To do this, nodes must be moved from
|
||||||
created with API version 1.11 and above must be moved from the ``enroll`` state
|
the ``enroll`` state to the ``manageable`` state and then to the ``available``
|
||||||
to the ``manageable`` state and then to the ``available`` state.
|
state.
|
||||||
This section can be safely skipped, if API version 1.10 or earlier is used
|
|
||||||
(which is the case by default).
|
.. note::
|
||||||
|
This section can be skipped, if API version 1.10 or earlier is used.
|
||||||
|
|
||||||
After creating a node and before moving it from its initial provision state of
|
After creating a node and before moving it from its initial provision state of
|
||||||
``enroll``, basic power and port information needs to be configured on the node.
|
``enroll``, basic power and port information needs to be configured on the node.
|
||||||
|
Loading…
Reference in New Issue
Block a user