From 8a87fc6fcb8c6ffc0b07f59c3cb27b738473cfa5 Mon Sep 17 00:00:00 2001 From: Dmitry Tantsur Date: Fri, 15 Dec 2017 17:46:46 +0100 Subject: [PATCH] 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 | 16 ++-- doc/source/admin/cleaning.rst | 43 +++++---- doc/source/admin/console.rst | 35 ++++++-- doc/source/admin/drivers/ipa.rst | 27 +++--- doc/source/admin/drivers/ipmitool.rst | 10 --- doc/source/admin/drivers/snmp.rst | 44 +++++---- doc/source/admin/inspection.rst | 73 +++++++-------- doc/source/admin/notifications.rst | 123 +++++++++++++------------- doc/source/admin/raid.rst | 20 +++-- 9 files changed, 198 insertions(+), 193 deletions(-) diff --git a/doc/source/admin/adoption.rst b/doc/source/admin/adoption.rst index 7dec6b4a9d..daa7803c27 100644 --- a/doc/source/admin/adoption.rst +++ b/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`` -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= \ --driver-info ipmi_username= \ --driver-info ipmi_password= \ diff --git a/doc/source/admin/cleaning.rst b/doc/source/admin/cleaning.rst index 470710cdd2..85d5fde3e9 100644 --- a/doc/source/admin/cleaning.rst +++ b/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, -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? ---------------------------------------------------- diff --git a/doc/source/admin/console.rst b/doc/source/admin/console.rst index e8da82b1e4..ad30e54095 100644 --- a/doc/source/admin/console.rst +++ b/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 \ + --console-interface ipmitool-shellinabox + Enable the web console, for example:: openstack baremetal node set \ @@ -116,7 +129,7 @@ The web console can be configured in Bare Metal service in the following way: openstack baremetal driver property list - 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 ````, 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 \ + --console-interface ipmitool-socat + Enable the serial console, for example:: openstack baremetal node set --driver-info ipmi_terminal_port= diff --git a/doc/source/admin/drivers/ipa.rst b/doc/source/admin/drivers/ipa.rst index 19f751da1e..8a9b0ebe86 100644 --- a/doc/source/admin/drivers/ipa.rst +++ b/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 -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 ====================== diff --git a/doc/source/admin/drivers/ipmitool.rst b/doc/source/admin/drivers/ipmitool.rst index a842047140..60fee146b5 100644 --- a/doc/source/admin/drivers/ipmitool.rst +++ b/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. diff --git a/doc/source/admin/drivers/snmp.rst b/doc/source/admin/drivers/snmp.rst index 81faf80035..5c06a0e9af 100644 --- a/doc/source/admin/drivers/snmp.rst +++ b/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 -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. diff --git a/doc/source/admin/inspection.rst b/doc/source/admin/inspection.rst index 5e5517d2cc..582e3860d1 100644 --- a/doc/source/admin/inspection.rst +++ b/doc/source/admin/inspection.rst @@ -16,33 +16,29 @@ to the `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 -* Initiate inspection:: +Then inspection can be initiated using the following command:: openstack baremetal node inspect -.. 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 ` 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 diff --git a/doc/source/admin/notifications.rst b/doc/source/admin/notifications.rst index c547b268ef..8e2d81dcda 100644 --- a/doc/source/admin/notifications.rst +++ b/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, - "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": { diff --git a/doc/source/admin/raid.rst b/doc/source/admin/raid.rst index 808c022e36..4b724aa5e4 100644 --- a/doc/source/admin/raid.rst +++ b/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 -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 ``. 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 @@ -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