Switch non-vendor parts admin guide to hardware types

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

doc/source/admin/adoption.rst

@@ -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``
+The takeover process involves the deploy interface's ``prepare`` and
-methods being called. These steps take driver specific actions such as
+``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> \

doc/source/admin/cleaning.rst

@@ -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,
+ironic hardware types used for nodes. This includes, by default, erasing all
-erasing all of the previous tenant's data.
+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
+on the node using a deploy interface. Currently, all the deploy interfaces
-ironic-python-agent ramdisk support in-band cleaning. By default,
+support in-band cleaning. By default, ironic-python-agent ships with a minimal
-ironic-python-agent ships with a minimal cleaning configuration, only erasing
+cleaning configuration, only erasing disks. However, you can add your own
-disks. However, with this ramdisk, you can add your own cleaning steps and/or
+cleaning steps and/or override default cleaning steps with a custom
-override default cleaning steps with a custom Hardware Manager.
+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
+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.
+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,
+across hardware interfaces, the following resolution order is used:
-Deploy, and RAID interfaces.
+
+#. 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?
 ----------------------------------------------------

doc/source/admin/console.rst

@@ -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`_.
+Serial consoles for nodes are implemented using `socat`_. It is supported by
-In Newton, the following drivers support socat consoles for nodes:
+the ``ipmi`` and ``irmc`` hardware types.
-
-* agent_ipmitool_socat
-* pxe_ipmitool_socat
 
 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>

doc/source/admin/drivers/ipa.rst

@@ -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
+Starting with the Kilo release all deploy interfaces (except for fake ones)
-IPA for deployment. There are two types of them, which can be distinguished
+are using IPA. There are two types of them:
-by prefix:
 
 * 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
+Which one to choose depends on your environment. :ref:`iscsi-deploy` puts
-higher load on conductors, agent-based drivers currently require the whole
+higher load on conductors, :ref:`direct-deploy` currently requires the whole
-image to fit in the node's memory.
+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
+When using the :ref:`direct-deploy`, IPA supports using proxies for downloading
-could be used to speed up download by using caching proxy.
+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``
+   proxy.
-   output of the ``agent_*`` driver you're using for descriptions of these
-   properties.
 
 Advanced configuration
 ======================

doc/source/admin/drivers/ipmitool.rst

@@ -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.

doc/source/admin/drivers/snmp.rst

@@ -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
+The SNMP power interface works with the :ref:`pxe-boot` interface for network
-network-configured boot.
+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
+      It is important to set ``boot_option`` to ``netboot`` as SNMP hardware
-      do not support setting of boot devices. One can also configure a node
+      type does not support setting of boot devices. One can also configure
-      to boot using ``netboot`` by setting its ``capabilities`` and updating
+      a node to boot using ``netboot`` by setting its ``capabilities`` and
-      Nova flavor as described below:
+      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
+Nodes configured to use the SNMP hardware type should have the ``driver`` field
-set to the hardware type ``snmp`` (preferred) or to the classic driver
+set to the hardware type ``snmp``.
-``pxe_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.

doc/source/admin/inspection.rst

@@ -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
+#. Out-of-band inspection is currently implemented by several hardware types,
-   :ref:`ilo`.
+   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 the ``manageable`` state before inspection is initiated.
-The node should be in MANAGEABLE state before inspection is initiated.
+If it is in the ``enroll`` or ``available`` state, move it to ``manageable``
-
+first::
-* Move node to manageable state::
 
     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
+inspection. The exact support is hardware and hardware type specific though,
-list is provided by the iLO :ref:`ilo-inspection`.
+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
+Please see a specific :doc:`hardware type page </admin/drivers>` for
-driver can discover.
+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
+.. code-block:: ini
-    pxe_ipminative
-    agent_ipmitool
-    agent_ipminative
-    fake_inspector
 
-It is also the default inspection approach for the following vendor drivers::
+    [DEFAULT]
+    enabled_inspect_interfaces = inspector,no-inspect
 
-    pxe_drac
+If using classic drivers supporting in-band inspection, like ``pxe_ipmitool``,
-    pxe_ucs
+another option has to be set as well:
-    pxe_cimc
+
-    agent_ucs
+.. code-block:: ini
-    agent_cimc
+
+    [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
+If the ironic-inspector service is not registered in the service catalog, set
-non-standard port.
+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

doc/source/admin/notifications.rst

@@ -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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "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,
+            "boot_interface": "pxe",
-            "console_interface": None,
+            "console_interface": "no-console",
-            "deploy_interface": None,
+            "deploy_interface": "iscsi",
-            "inspect_interface": None,
+            "inspect_interface": "no-inspect",
-            "management_interface": None,
+            "management_interface": "ipmitool",
             "network_interface": "flat",
-            "power_interface": None,
+            "power_interface": "ipmitool",
-            "raid_interface": None,
+            "raid_interface": "no-raid",
-            "storage_interface": None,
+            "storage_interface": "noop",
-            "vendor_interface": None,
+            "vendor_interface": "no-vendor",
             "name": None,
             "power_state": "power off",
             "properties": {

doc/source/admin/raid.rst

@@ -17,14 +17,14 @@ for their corresponding REST API requests.
 
 Prerequisites
 =============
-The bare metal node needs to use a driver that supports RAID
+The bare metal node needs to use a hardware type that supports RAID
-configuration. Drivers may implement RAID configuration either in-band or
+configuration. RAID interfaces may implement RAID configuration either in-band
-out-of-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