openstack/ironic
Code Issues Proposed changes

Switch non-vendor parts admin guide to hardware types

Browse Source 
This change makes the admin guide use hardware types for examples and
explanations. The in-band inspection document was updated with recent
changes.

Vendor driver documentation requires more careful review, and ideally
should be updated by vendor representatives.

Change-Id: I98a2eb905e352502a7f9f4cb1804c9d64489ec47
Partial-Bug: #1690185
This commit is contained in:
Dmitry Tantsur 2017-12-15 17:46:46 +01:00
parent 75499e1ccf
commit 8a87fc6fcb
9 changed files with 198 additions and 193 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/source/admin/adoption.rst
View File

@ -26,17 +26,17 @@ How it works
============
A node initially enrolled begins in the ``enroll`` state. An operator
must then move the node to ``manageable`` state, which causes the driver's
must then move the node to ``manageable`` state, which causes the node's
``power`` interface to be validated. Once in ``manageable`` state,
an operator can then explicitly choose to adopt a node.
Adoption of a node results in the validation of the driver ``boot`` interface,
Adoption of a node results in the validation of its ``boot`` interface,
and upon success the process leverages what is referred to as the "takeover"
logic. The takeover process is intended for conductors to take over the
management of nodes for a conductor that has failed.
The takeover process involves the driver deploy ``prepare`` and ``take_over``
methods being called. These steps take driver specific actions such as
The takeover process involves the deploy interface's ``prepare`` and
``take_over`` methods being called. These steps take specific actions such as
downloading and staging the deployment kernel and ramdisk, ISO image, any
required boot image, or boot ISO image and then places any PXE or virtual
media configuration necessary for the node should it be required.
@ -101,7 +101,7 @@ Requirements for use are essentially the same as to deploy a node:
* Sufficient driver information to allow for a successful
power management validation.
* Sufficient instance_info to pass deploy driver preparation.
* Sufficient instance_info to pass deploy interface preparation.
Each driver may have additional requirements dependent upon the
configuration that is supplied. An example of this would be defining
@ -110,8 +110,8 @@ to attempt to retrieve the pertinent files. Inability to do so will
result in the adoption failing, and the node being placed in the
``adopt failed`` state.
agent_ipmitool example
----------------------
Example
-------
This is an example to create a new node, named ``testnode``, with
sufficient information to pass basic validation in order to be taken
@ -122,7 +122,7 @@ from the ``manageable`` state to ``active`` state::
export OS_BAREMETAL_API_VERSION=1.17
openstack baremetal node create --name testnode \
--driver agent_ipmitool \
--driver ipmi \
--driver-info ipmi_address=<ip_address> \
--driver-info ipmi_username=<username> \
--driver-info ipmi_password=<password> \

43
doc/source/admin/cleaning.rst
View File

@ -43,15 +43,17 @@ Ironic added support for automated cleaning in the Kilo release.
Enabling automated cleaning
---------------------------
To enable automated cleaning, ensure that your ironic.conf is set as follows.
(Prior to Mitaka, this option was named 'clean_nodes'.)::
To enable automated cleaning, ensure that your ironic.conf is set as follows:
.. code-block:: ini
[conductor]
automated_clean=true
This will enable the default set of cleaning steps, based on your hardware and
ironic drivers. If you're using an agent_* driver, this includes, by default,
erasing all of the previous tenant's data.
ironic hardware types used for nodes. This includes, by default, erasing all
of the previous tenant's data.
You may also need to configure a `Cleaning Network`_.
@ -60,7 +62,7 @@ Cleaning steps
Cleaning steps used for automated cleaning are ordered from higher to lower
priority, where a larger integer is a higher priority. In case of a conflict
between priorities across drivers, the following resolution order is used:
between priorities across interfaces, the following resolution order is used:
Power, Management, Deploy, and RAID interfaces.
You can skip a cleaning step by setting the priority for that cleaning step
@ -146,7 +148,7 @@ An example of the request body for this API::
}]
}
In the above example, the driver's RAID interface would configure hardware
In the above example, the node's RAID interface would configure hardware
RAID without non-root volumes, and then all devices would be erased
(in that order).
@ -206,19 +208,20 @@ out-of-band. Ironic supports using both methods to clean a node.
In-band
-------
In-band steps are performed by ironic making API calls to a ramdisk running
on the node using a Deploy driver. Currently, all the drivers using
ironic-python-agent ramdisk support in-band cleaning. By default,
ironic-python-agent ships with a minimal cleaning configuration, only erasing
disks. However, with this ramdisk, you can add your own cleaning steps and/or
override default cleaning steps with a custom Hardware Manager.
on the node using a deploy interface. Currently, all the deploy interfaces
support in-band cleaning. By default, ironic-python-agent ships with a minimal
cleaning configuration, only erasing disks. However, you can add your own
cleaning steps and/or override default cleaning steps with a custom
Hardware Manager.
Out-of-band
-----------
Out-of-band are actions performed by your management controller, such as IPMI,
iLO, or DRAC. Out-of-band steps will be performed by ironic using a Power or
Management driver. Which steps are performed depends on the driver and hardware.
iLO, or DRAC. Out-of-band steps will be performed by ironic using a power or
management interface. Which steps are performed depends on the hardware type
and hardware itself.
For Out-of-Band cleaning operations supported by iLO drivers, refer to
For Out-of-Band cleaning operations supported by iLO hardware types, refer to
:ref:`ilo_node_cleaning`.
FAQ
@ -228,8 +231,12 @@ How are cleaning steps ordered?
-------------------------------
For automated cleaning, cleaning steps are ordered by integer priority, where
a larger integer is a higher priority. In case of a conflict between priorities
across drivers, the following resolution order is used: Power, Management,
Deploy, and RAID interfaces.
across hardware interfaces, the following resolution order is used:
#. Power interface
#. Management interface
#. Deploy interface
#. RAID interface
For manual cleaning, the cleaning steps should be specified in the desired
order.
@ -257,7 +264,7 @@ to disable erase_devices, you'd set the following configuration option::
[deploy]
erase_devices_priority=0
To enable/disable the in-band disk erase using ``agent_ilo`` driver, use the
To enable/disable the in-band disk erase using ``ilo`` hardware type, use the
following configuration option::
[ilo]
@ -292,7 +299,7 @@ some tradeoffs to having it enabled. For instance, ironic cannot deploy a new
instance to a node that is currently cleaning, and cleaning can be a time
consuming process. To mitigate this, we suggest using disks with support for
cryptographic ATA Security Erase, as typically the erase_devices step in the
deploy driver takes the longest time to complete of all cleaning steps.
deploy interface takes the longest time to complete of all cleaning steps.
Why can't I power on/off a node while it's cleaning?
----------------------------------------------------

35
doc/source/admin/console.rst
View File

@ -94,8 +94,21 @@ The web console can be configured in Bare Metal service in the following way:
configuration file (/etc/ironic/ironic.conf). See the reference for
configuration in :ref:`kernel-boot-parameters`.
* Enable the ``ipmitool-shellinabox`` console interface, for example:
.. code-block:: ini
[DEFAULT]
enabled_console_interfaces = ipmitool-shellinabox,no-console
* Configure node web console.
If the node uses a hardware type, for example ``ipmi``, set the node's
console interface to ``ipmitool-shellinabox``::
openstack --os-baremetal-api-version 1.31 baremetal node set <node-uuid> \
--console-interface ipmitool-shellinabox
Enable the web console, for example::
openstack baremetal node set <node-uuid> \
@ -116,7 +129,7 @@ The web console can be configured in Bare Metal service in the following way:
openstack baremetal driver property list <driver>
For ``*_ipmitool`` and ``*_ipminative`` drivers, this option is ``ipmi_terminal_port``.
For the ``ipmi`` hardware type, this option is ``ipmi_terminal_port``.
Give a customized port number to ``<customized_port>``,
for example ``8023``, this customized port is used in web console url.
@ -142,11 +155,8 @@ The web console can be configured in Bare Metal service in the following way:
Node serial console
-------------------
Serial consoles for nodes are implemented using `socat`_.
In Newton, the following drivers support socat consoles for nodes:
* agent_ipmitool_socat
* pxe_ipmitool_socat
Serial consoles for nodes are implemented using `socat`_. It is supported by
the ``ipmi`` and ``irmc`` hardware types.
Serial consoles can be configured in the Bare Metal service as follows:
@ -168,8 +178,21 @@ Serial consoles can be configured in the Bare Metal service as follows:
service configuration file. See the reference on how to configure them in
:ref:`kernel-boot-parameters`.
* Enable the ``ipmitool-socat`` console interface, for example:
.. code-block:: ini
[DEFAULT]
enabled_console_interfaces = ipmitool-socat,no-console
* Configure node console.
If the node uses a hardware type, for example ``ipmi``, set the node's
console interface to ``ipmitool-socat``::
openstack --os-baremetal-api-version 1.31 baremetal node set <node-uuid> \
--console-interface ipmitool-socat
Enable the serial console, for example::
openstack baremetal node set <node-uuid> --driver-info ipmi_terminal_port=<port>

27
doc/source/admin/drivers/ipa.rst
View File

@ -17,9 +17,8 @@ For more information see the `ironic-python-agent documentation
Drivers
=======
Starting with the Kilo release all drivers (except for fake ones) are using
IPA for deployment. There are two types of them, which can be distinguished
by prefix:
Starting with the Kilo release all deploy interfaces (except for fake ones)
are using IPA. There are two types of them:
* For nodes using the :ref:`iscsi-deploy` interface, IPA exposes the root hard
drive as an iSCSI share and calls back to the ironic conductor. The
@ -32,28 +31,28 @@ by prefix:
process: downloading an image from swift, putting it on the machine and doing
any post-deploy actions.
Which one to choose depends on your environment. iSCSI-based drivers put
higher load on conductors, agent-based drivers currently require the whole
image to fit in the node's memory.
Which one to choose depends on your environment. :ref:`iscsi-deploy` puts
higher load on conductors, :ref:`direct-deploy` currently requires the whole
image to fit in the node's memory, except when using raw images. It also
requires :doc:`/install/configure-glance-swift`.
.. todo: other differences?
.. todo: explain configuring swift for temporary URL's
Requirements
------------
Using IPA requires it to be present and configured on the deploy ramdisk, see
:ref:`deploy-ramdisk`
Using proxies for image download in agent drivers
=================================================
Using proxies for image download
================================
Overview
--------
IPA supports using proxies while downloading the user image. For example, this
could be used to speed up download by using caching proxy.
When using the :ref:`direct-deploy`, IPA supports using proxies for downloading
the user image. For example, this could be used to speed up download by using
a caching proxy.
Steps to enable proxies
-----------------------
@ -100,9 +99,7 @@ Steps to enable proxies
#. Add one or more of ``image_http_proxy``, ``image_https_proxy``,
``image_no_proxy`` to driver_info properties in each node that will use the
proxy. Please refer to the ``openstack baremetal driver property list``
output of the ``agent_*`` driver you're using for descriptions of these
properties.
proxy.
Advanced configuration
======================

10
doc/source/admin/drivers/ipmitool.rst
View File

@ -45,16 +45,6 @@ Please see :doc:`/install/configure-ipmi` for the required dependencies.
[DEFAULT]
enabled_hardware_types = ipmi
#. The ``pxe_ipmitool`` classic driver is enabled by default. To enable one or
more of the other IPMI classic drivers, add them to the
``enabled_drivers`` configuration option in your ``ironic.conf``.
The following enables ``pxe_ipmitool`` and ``agent_ipmitool`` drivers:
.. code-block:: ini
[DEFAULT]
enabled_drivers = pxe_ipmitool,agent_ipmitool
#. Restart the Ironic conductor service.
Please see :doc:`/install/enabling-drivers` for more details.

44
doc/source/admin/drivers/snmp.rst
View File

@ -2,12 +2,17 @@
SNMP driver
===========
The SNMP power driver enables control of power distribution units of the type
The SNMP hardware type enables control of power distribution units of the type
frequently found in data centre racks. PDUs frequently have a management
ethernet interface and SNMP support enabling control of the power outlets.
The SNMP power driver works with the PXE driver for network deployment and
network-configured boot.
The SNMP power interface works with the :ref:`pxe-boot` interface for network
deployment and network-configured boot.
.. note::
Unlike most of the other power interfaces, the SNMP power interface does
not have a corresponding management interface. The SNMP hardware type uses
the ``fake`` management interface instead.
List of supported devices
=========================
@ -57,8 +62,8 @@ Software Requirements
- The PySNMP package must be installed, variously referred to as ``pysnmp``
or ``python-pysnmp``
Enabling the SNMP Power Driver
==============================
Enabling the SNMP Hardware Type
===============================
#. Add ``snmp`` to the list of ``enabled_hardware_types`` in ``ironic.conf``.
Also update ``enabled_management_interfaces`` and
@ -71,15 +76,6 @@ Enabling the SNMP Power Driver
enabled_management_interfaces = fake
enabled_power_interfaces = snmp
#. Alternatively, if you prefer using the classic driver instead of the
``snmp`` hardware type, add ``pxe_snmp`` to the list of ``enabled_drivers``
in ``ironic.conf``:
.. code-block:: ini
[DEFAULT]
enabled_drivers = pxe_snmp
#. To set the default boot option, update ``default_boot_option`` in
``ironic.conf``:
@ -94,10 +90,10 @@ Enabling the SNMP Power Driver
to set an explicit value for this option.
.. note::
It is important to set ``boot_option`` to ``netboot`` as SNMP drivers
do not support setting of boot devices. One can also configure a node
to boot using ``netboot`` by setting its ``capabilities`` and updating
Nova flavor as described below:
It is important to set ``boot_option`` to ``netboot`` as SNMP hardware
type does not support setting of boot devices. One can also configure
a node to boot using ``netboot`` by setting its ``capabilities`` and
updating Nova flavor as described below:
.. code-block:: console
@ -114,9 +110,8 @@ Enabling the SNMP Power Driver
Ironic Node Configuration
=========================
Nodes configured to use the SNMP driver should have the ``driver`` field
set to the hardware type ``snmp`` (preferred) or to the classic driver
``pxe_snmp``.
Nodes configured to use the SNMP hardware type should have the ``driver`` field
set to the hardware type ``snmp``.
The following property values have to be added to the node's
``driver_info`` field:
@ -134,7 +129,8 @@ The following property values have to be added to the node's
- ``snmp_security``: (Required for SNMPv3) SNMPv3 User-based Security Model
(USM) user name.
The following command can be used to enroll a node with the ``snmp`` driver:
The following command can be used to enroll a node with the ``snmp`` hardware
type:
.. code-block:: bash
@ -148,8 +144,8 @@ The following command can be used to enroll a node with the ``snmp`` driver:
PDU Configuration
=================
This version of the SNMP power driver does not support SNMPv3 authentication
This version of the SNMP power interface does not support SNMPv3 authentication
or encryption features. When using SNMPv3, the SNMPv3 agent at the PDU must
be configured in ``noAuthNoPriv`` mode. Also, the ``snmp_security`` parameter
is used to configure SNMP USM user name to the SNMP manager at the power
driver. The same USM user name must be configured to the target SNMP agent.
interface. The same USM user name must be configured to the target SNMP agent.

73
doc/source/admin/inspection.rst
View File

@ -16,33 +16,29 @@ to the `bug 1405131 <https://bugs.launchpad.net/ironic/+bug/1405131>`_.
There are two kinds of inspection supported by Bare Metal service:
#. Out-of-band inspection is currently implemented by iLO drivers, listed at
:ref:`ilo`.
#. Out-of-band inspection is currently implemented by several hardware types,
including ``ilo``, ``idrac`` and ``irmc``.
#. `In-band inspection`_ by utilizing the ironic-inspector_ project.
Inspection can be initiated using node-set-provision-state.
The node should be in MANAGEABLE state before inspection is initiated.
* Move node to manageable state::
The node should be in the ``manageable`` state before inspection is initiated.
If it is in the ``enroll`` or ``available`` state, move it to ``manageable``
first::
openstack baremetal node manage <node_UUID>
* Initiate inspection::
Then inspection can be initiated using the following command::
openstack baremetal node inspect <node_UUID>
.. note::
The above commands require the python-ironicclient_ to be version 0.5.0 or greater.
.. _capabilities-discovery:
Capabilities discovery
----------------------
This is an incomplete list of capabilities we want to discover during
inspection. The exact support is driver-specific though, the most complete
list is provided by the iLO :ref:`ilo-inspection`.
inspection. The exact support is hardware and hardware type specific though,
the most complete list is provided by the iLO :ref:`ilo-inspection`.
``secure_boot`` (``true`` or ``false``)
whether secure boot is supported for the node
@ -69,8 +65,8 @@ for scheduling::
nova flavor-key my-baremetal-flavor set capabilities:secure_boot="true"
Please see a specific driver page for the exact list of capabilities this
driver can discover.
Please see a specific :doc:`hardware type page </admin/drivers>` for
the exact list of capabilities this hardware type can discover.
In-band inspection
------------------
@ -81,29 +77,33 @@ than the out-of-band inspection, but it is not vendor-specific and works
across a wide range of hardware. In-band inspection is using the
ironic-inspector_ project.
Currently it is supported by the following generic drivers::
It is supported by all hardware types, and used by default, if enabled, by the
``ipmi`` hardware type. The ``inspector`` *inspect* interface has to be
enabled to use it:
pxe_ipmitool
pxe_ipminative
agent_ipmitool
agent_ipminative
fake_inspector
.. code-block:: ini
It is also the default inspection approach for the following vendor drivers::
[DEFAULT]
enabled_inspect_interfaces = inspector,no-inspect
pxe_drac
pxe_ucs
pxe_cimc
agent_ucs
agent_cimc
If using classic drivers supporting in-band inspection, like ``pxe_ipmitool``,
another option has to be set as well:
.. code-block:: ini
[inspector]
enabled = True
This feature needs to be explicitly enabled in the ironic configuration file
by setting ``enabled = True`` in ``[inspector]`` section.
You must additionally install python-ironic-inspector-client_ to use
this functionality.
You must set ``service_url`` if the ironic-inspector service is
being run on a separate host from the ironic-conductor service, or is using
non-standard port.
If the ironic-inspector service is not registered in the service catalog, set
the following option:
.. code-block:: ini
[inspector]
endpoint-override = http://inspector.example.com:5050
In order to ensure that ports in Bare Metal service are synchronized with
NIC ports on the node, the following settings in the ironic-inspector
@ -113,17 +113,6 @@ configuration file must be set::
add_ports = all
keep_ports = present
.. note::
During Kilo cycle we used an older version of Inspector called
ironic-discoverd_. Inspector is expected to be a mostly drop-in
replacement, and the same client library should be used to connect to both.
For Kilo, install ironic-discoverd_ of version 1.1.0 or higher
instead of python-ironic-inspector-client and use ``[discoverd]`` option
group in both Bare Metal service and ironic-discoverd configuration
files instead of ones provided above.
.. _ironic-inspector: https://pypi.python.org/pypi/ironic-inspector
.. _ironic-discoverd: https://pypi.python.org/pypi/ironic-discoverd
.. _python-ironic-inspector-client: https://pypi.python.org/pypi/python-ironic-inspector-client
.. _python-ironicclient: https://pypi.python.org/pypi/python-ironicclient

123
doc/source/admin/notifications.rst
View File

@ -138,9 +138,10 @@ Example of node CRUD notification::
"clean_step": None,
"console_enabled": False,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"driver_info": {
"host": "192.168.0.111"},
"ipmi_address": "192.168.0.111",
"ipmi_username": "root"},
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -149,16 +150,16 @@ Example of node CRUD notification::
"last_error": None,
"maintenance": False,
"maintenance_reason": None,
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {
@ -358,7 +359,7 @@ node maintenance notification::
"clean_step": None,
"console_enabled": False,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -367,16 +368,16 @@ node maintenance notification::
"last_error": None,
"maintenance": True,
"maintenance_reason": "hw upgrade",
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {
@ -434,7 +435,7 @@ notification::
"clean_step": None,
"console_enabled": True,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -443,16 +444,16 @@ notification::
"last_error": None,
"maintenance": False,
"maintenance_reason": None,
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {
@ -503,7 +504,7 @@ ironic-conductor is attempting to change the node::
"clean_step": None,
"console_enabled": False,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -511,16 +512,16 @@ ironic-conductor is attempting to change the node::
"last_error": None,
"maintenance": False,
"maintenance_reason": None,
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {
@ -566,7 +567,7 @@ prior to the correction::
"clean_step": None,
"console_enabled": False,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -574,16 +575,16 @@ prior to the correction::
"last_error": None,
"maintenance": False,
"maintenance_reason": None,
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {
@ -640,7 +641,7 @@ indicate a node's provision states before state change, "event" is the FSM
"clean_step": None,
"console_enabled": False,
"created_at": "2016-01-26T20:41:03+00:00",
"driver": "fake",
"driver": "ipmi",
"extra": {},
"inspection_finished_at": None,
"inspection_started_at": None,
@ -649,16 +650,16 @@ indicate a node's provision states before state change, "event" is the FSM
"last_error": None,
"maintenance": False,
"maintenance_reason": None,
"boot_interface": None,
"console_interface": None,
"deploy_interface": None,
"inspect_interface": None,
"management_interface": None,
"boot_interface": "pxe",
"console_interface": "no-console",
"deploy_interface": "iscsi",
"inspect_interface": "no-inspect",
"management_interface": "ipmitool",
"network_interface": "flat",
"power_interface": None,
"raid_interface": None,
"storage_interface": None,
"vendor_interface": None,
"power_interface": "ipmitool",
"raid_interface": "no-raid",
"storage_interface": "noop",
"vendor_interface": "no-vendor",
"name": None,
"power_state": "power off",
"properties": {

20
doc/source/admin/raid.rst
View File

@ -17,14 +17,14 @@ for their corresponding REST API requests.
Prerequisites
=============
The bare metal node needs to use a driver that supports RAID
configuration. Drivers may implement RAID configuration either in-band or
out-of-band.
The bare metal node needs to use a hardware type that supports RAID
configuration. RAID interfaces may implement RAID configuration either in-band
or out-of-band.
In-band RAID configuration is done using the Ironic Python Agent
ramdisk. For in-band RAID configuration using agent ramdisk, a hardware
manager which supports RAID should be bundled with the ramdisk.
The drivers supporting RAID configuration could be found using the CLI
Whether a node supports RAID configuration could be found using the CLI
command ``openstack baremetal node validate <node-uuid>``.
Build agent ramdisk which supports RAID configuration
@ -66,7 +66,8 @@ If the ``target_raid_config`` is an empty dictionary, it unsets the value of
done on the node.
Each dictionary of logical disk contains the desired properties of logical
disk supported by the driver. These properties are discoverable by::
disk supported by the hardware type or classic driver. These properties are
discoverable by::
openstack baremetal --os-baremetal-api-version 1.15 driver raid property list <driver name>
@ -103,7 +104,7 @@ The RAID properties can be split into 4 different types:
- ``is_root_volume`` - Set to ``true`` if this is the root volume. At
most one logical disk can have this set to ``true``; the other
logical disks must have this set to ``false``. The
``root device hint`` will be saved, if the driver is capable of
``root device hint`` will be saved, if the RAID interface is capable of
retrieving it. This is ``false`` by default.
#. Backing physical disk hints. These hints are specified for each logical
@ -133,9 +134,9 @@ The RAID properties can be split into 4 different types:
on a wider range of attributes (eg. S.M.A.R.T. status, physical location).
The values for these properties are hardware dependent.
- ``controller`` - The name of the controller as read by the driver.
- ``controller`` - The name of the controller as read by the RAID interface.
- ``physical_disks`` - A list of physical disks to use as read by the
driver.
RAID interface.
.. note::
If properties from both "Backing physical disk hints" or
@ -242,7 +243,8 @@ To get the current RAID configuration::
Workflow
========
* Operator configures the bare metal node with a driver that has a ``RAIDInterface``.
* Operator configures the bare metal node with a hardware type that has
a ``RAIDInterface`` other than ``no-raid`` (``None`` for classic drivers).
* For in-band RAID configuration, operator builds an agent ramdisk which
supports RAID configuration by bundling the hardware manager with the