Browse Source

Merge "Updates ironic documentation"

changes/42/756942/1
Zuul 2 years ago committed by Gerrit Code Review
parent
commit
cde792a8c3
  1. 16
      doc/source/admin/adoption.rst
  2. 4
      doc/source/admin/bios.rst
  3. 8
      doc/source/admin/boot-from-volume.rst
  4. 20
      doc/source/admin/cleaning.rst
  5. 2
      doc/source/admin/conductor-groups.rst
  6. 26
      doc/source/admin/console.rst
  7. 18
      doc/source/admin/drivers.rst
  8. 4
      doc/source/admin/drivers/ansible.rst
  9. 4
      doc/source/admin/drivers/ibmc.rst
  10. 32
      doc/source/admin/drivers/idrac.rst
  11. 26
      doc/source/admin/drivers/ilo.rst
  12. 12
      doc/source/admin/drivers/intel-ipmi.rst
  13. 2
      doc/source/admin/drivers/ipa.rst
  14. 16
      doc/source/admin/drivers/ipmitool.rst
  15. 12
      doc/source/admin/drivers/irmc.rst
  16. 16
      doc/source/admin/drivers/redfish.rst
  17. 4
      doc/source/admin/drivers/snmp.rst
  18. 4
      doc/source/admin/drivers/xclarity.rst
  19. 4
      doc/source/admin/inspection.rst
  20. 2
      doc/source/admin/interfaces/boot.rst
  21. 16
      doc/source/admin/interfaces/deploy.rst
  22. 12
      doc/source/admin/multitenancy.rst
  23. 14
      doc/source/admin/node-deployment.rst
  24. 4
      doc/source/admin/node-multitenancy.rst
  25. 14
      doc/source/admin/raid.rst
  26. 10
      doc/source/admin/ramdisk-boot.rst
  27. 6
      doc/source/admin/rescue.rst
  28. 8
      doc/source/admin/retirement.rst
  29. 16
      doc/source/admin/troubleshooting.rst
  30. 22
      doc/source/admin/upgrade-to-hardware-types.rst
  31. 2
      doc/source/contributor/deploy-steps.rst
  32. 22
      doc/source/contributor/dev-quickstart.rst
  33. 2
      doc/source/contributor/drivers.rst
  34. 8
      doc/source/install/configdrive.rst
  35. 2
      doc/source/install/configure-ipv6-networking.rst
  36. 58
      doc/source/install/enrollment.rst
  37. 4
      doc/source/install/include/disk-label.inc
  38. 4
      doc/source/install/include/local-boot-partition-images.inc
  39. 6
      doc/source/install/include/root-device-hints.inc
  40. 4
      doc/source/install/include/trusted-boot.inc
  41. 34
      doc/source/install/standalone.rst
  42. 12
      doc/source/install/troubleshooting.rst

16
doc/source/admin/adoption.rst

@ -121,7 +121,7 @@ from the ``manageable`` state to ``active`` state::
# 1.17, which introduces the adoption capability.
export OS_BAREMETAL_API_VERSION=1.17
openstack baremetal node create --name testnode \
baremetal node create --name testnode \
--driver ipmi \
--driver-info ipmi_address=<ip_address> \
--driver-info ipmi_username=<username> \
@ -129,15 +129,15 @@ from the ``manageable`` state to ``active`` state::
--driver-info deploy_kernel=<deploy_kernel_id_or_url> \
--driver-info deploy_ramdisk=<deploy_ramdisk_id_or_url>
openstack baremetal port create <node_mac_address> --node <node_uuid>
baremetal port create <node_mac_address> --node <node_uuid>
openstack baremetal node set testnode \
baremetal node set testnode \
--instance-info image_source="http://localhost:8080/blankimage" \
--instance-info capabilities="{\"boot_option\": \"local\"}"
openstack baremetal node manage testnode --wait
baremetal node manage testnode --wait
openstack baremetal node adopt testnode --wait
baremetal node adopt testnode --wait
.. NOTE::
In the above example, the image_source setting must reference a valid
@ -160,7 +160,7 @@ from the ``manageable`` state to ``active`` state::
used to match an instance in the Compute service. Doing so is not
required for the proper operation of the Bare Metal service.
openstack baremetal node set <node name or uuid> --instance-uuid <uuid>
baremetal node set <node name or uuid> --instance-uuid <uuid>
.. NOTE::
In Newton, coupled with API version 1.20, the concept of a
@ -186,7 +186,7 @@ If a user wishes to abort their attempt at adopting, they can then move
the node back to ``manageable`` from ``adopt failed`` state by issuing the
``manage`` verb. Example::
openstack baremetal node manage <node name or uuid>
baremetal node manage <node name or uuid>
If all else fails the hardware node can be removed from the Bare Metal
service. The ``node delete`` command, which is **not** the same as setting
@ -194,4 +194,4 @@ the provision state to ``deleted``, can be used while the node is in
``adopt failed`` state. This will delete the node without cleaning
occurring to preserve the node's current state. Example::
openstack baremetal node delete <node name or uuid>
baremetal node delete <node name or uuid>

4
doc/source/admin/bios.rst

@ -51,7 +51,7 @@ Retrieve BIOS settings
To retrieve the cached BIOS configuration from a specified node::
$ openstack baremetal node bios setting list <node-uuid>
$ baremetal node bios setting list <node-uuid>
BIOS settings are cached on each node cleaning operation or when settings
have been applied successfully via BIOS cleaning steps. The return of above
@ -79,7 +79,7 @@ as following::
To get a specified BIOS setting for a node::
$ openstack baremetal node bios setting show <node-uuid> <setting-name>
$ baremetal node bios setting show <node-uuid> <setting-name>
If ``-f json`` is added as suffix to above command, it returns BIOS settings
as following::

8
doc/source/admin/boot-from-volume.rst

@ -146,11 +146,11 @@ contains more extensive validation, that is likely un-necessary in a
Setting the external storage interface::
openstack baremetal node set --storage-interface external $NODE_UUID
baremetal node set --storage-interface external $NODE_UUID
Setting a volume::
openstack baremetal volume target create --node $NODE_UUID \
baremetal volume target create --node $NODE_UUID \
--type iscsi --boot-index 0 --volume-id $VOLUME_UUID \
--property target_iqn="iqn.2010-10.com.example:vol-X" \
--property target_lun="0" \
@ -161,12 +161,12 @@ Setting a volume::
Ensure that no image_source is defined::
openstack baremetal node unset \
baremetal node unset \
--instance-info image_source $NODE_UUID
Deploy the node::
openstack baremetal node deploy $NODE_UUID
baremetal node deploy $NODE_UUID
Upon deploy, the boot interface for the baremetal node will attempt
to either create iPXE configuration OR set boot parameters out-of-band via

20
doc/source/admin/cleaning.rst

@ -154,10 +154,10 @@ 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).
Starting manual cleaning via "openstack baremetal" CLI
Starting manual cleaning via "openstack metal" CLI
------------------------------------------------------
Manual cleaning is available via the ``openstack baremetal node clean``
Manual cleaning is available via the ``baremetal node clean``
command, starting with Bare Metal API version 1.15.
The argument ``--clean-steps`` must be specified. Its value is one of:
@ -175,20 +175,20 @@ add ``--os-baremetal-api-version 1.15`` to the command.)::
Examples of doing this with a JSON string::
openstack baremetal node clean <node> \
baremetal node clean <node> \
--clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]'
openstack baremetal node clean <node> \
baremetal node clean <node> \
--clean-steps '[{"interface": "deploy", "step": "erase_devices"}]'
Or with a file::
openstack baremetal node clean <node> \
baremetal node clean <node> \
--clean-steps my-clean-steps.txt
Or with stdin::
cat my-clean-steps.txt | openstack baremetal node clean <node> \
cat my-clean-steps.txt | baremetal node clean <node> \
--clean-steps -
Cleaning Network
@ -289,7 +289,7 @@ To check what cleaning step the node is performing or attempted to perform and
failed, run the following command; it will return the value in the node's
``driver_internal_info`` field::
openstack baremetal node show $node_ident -f value -c driver_internal_info
baremetal node show $node_ident -f value -c driver_internal_info
The ``clean_steps`` field will contain a list of all remaining steps with their
priorities, and the first one listed is the step currently in progress or that
@ -326,7 +326,7 @@ A ``clean failed`` node can be moved to ``manageable`` state, where it cannot
be scheduled by nova and you can safely attempt to fix the node. To move a node
from ``clean failed`` to ``manageable``::
openstack baremetal node manage $node_ident
baremetal node manage $node_ident
You can now take actions on the node, such as replacing a bad disk drive.
@ -341,10 +341,10 @@ to allow it to be scheduled by nova.
::
# First, move it out of maintenance mode
openstack baremetal node maintenance unset $node_ident
baremetal node maintenance unset $node_ident
# Now, make the node available for scheduling by nova
openstack baremetal node provide $node_ident
baremetal node provide $node_ident
The node will begin automated cleaning from the start, and move to
``available`` state when complete.

2
doc/source/admin/conductor-groups.rst

@ -58,7 +58,7 @@ expression.
#. Set the conductor group on one or more nodes::
openstack baremetal node set \
baremetal node set \
--conductor-group "OperatorDefinedString" <uuid>
#. As desired and as needed, remaining conductors can be updated with

26
doc/source/admin/console.rst

@ -124,23 +124,23 @@ The web console can be configured in Bare Metal service in the following way:
Enable the web console, for example::
openstack baremetal node set <node-uuid> \
baremetal node set <node-uuid> \
--driver-info <terminal_port>=<customized_port>
openstack baremetal node console enable <node-uuid>
baremetal node console enable <node-uuid>
Check whether the console is enabled, for example::
openstack baremetal node validate <node-uuid>
baremetal node validate <node-uuid>
Disable the web console, for example::
openstack baremetal node console disable <node-uuid>
openstack baremetal node unset <node-uuid> --driver-info <terminal_port>
baremetal node console disable <node-uuid>
baremetal node unset <node-uuid> --driver-info <terminal_port>
The ``<terminal_port>`` is driver dependent. The actual name of this field can be
checked in driver properties, for example::
openstack baremetal driver property list <driver>
baremetal driver property list <driver>
For the ``ipmi`` hardware type, this option is ``ipmi_terminal_port``.
Give a customized port number to ``<customized_port>``,
@ -148,7 +148,7 @@ The web console can be configured in Bare Metal service in the following way:
Get web console information for a node as follows::
openstack baremetal node console show <node-uuid>
baremetal node console show <node-uuid>
+-----------------+----------------------------------------------------------------------+
| Property | Value |
+-----------------+----------------------------------------------------------------------+
@ -211,22 +211,22 @@ Serial consoles can be configured in the Bare Metal service as follows:
Enable the serial console, for example::
openstack baremetal node set <node-uuid> --driver-info ipmi_terminal_port=<port>
openstack baremetal node console enable <node-uuid>
baremetal node set <node-uuid> --driver-info ipmi_terminal_port=<port>
baremetal node console enable <node-uuid>
Check whether the serial console is enabled, for example::
openstack baremetal node validate <node-uuid>
baremetal node validate <node-uuid>
Disable the serial console, for example::
openstack baremetal node console disable <node-uuid>
openstack baremetal node unset <node-uuid> --driver-info <ipmi_terminal_port>
baremetal node console disable <node-uuid>
baremetal node unset <node-uuid> --driver-info <ipmi_terminal_port>
Serial console information is available from the Bare Metal service. Get
serial console information for a node from the Bare Metal service as follows::
openstack baremetal node console show <node-uuid>
baremetal node console show <node-uuid>
+-----------------+----------------------------------------------------------------------+
| Property | Value |
+-----------------+----------------------------------------------------------------------+

18
doc/source/admin/drivers.rst

@ -38,7 +38,7 @@ enrolling as described in :doc:`/install/enrollment`::
Any hardware interfaces can be specified on enrollment as well::
openstack baremetal node create --driver <hardware type> \
baremetal node create --driver <hardware type> \
--deploy-interface direct --<other>-interface <other implementation>
For the remaining interfaces the default value is assigned as described in
@ -50,7 +50,7 @@ Changing Hardware Interfaces
Hardware interfaces can be changed by the following command::
openstack baremetal node set <NODE> \
baremetal node set <NODE> \
--deploy-interface direct \
--<other>-interface <other implementation>
@ -65,8 +65,8 @@ field is updated, the final result must be consistent, that is, the resulting
hardware interfaces must be compatible with the new hardware type. This will
not work::
openstack baremetal node create --name test --driver fake-hardware
openstack baremetal node set test --driver ipmi
baremetal node create --name test --driver fake-hardware
baremetal node set test --driver ipmi
This is because the ``fake-hardware`` hardware type defaults to ``fake``
implementations for some or all interfaces, but the ``ipmi`` hardware type is
@ -74,7 +74,7 @@ not compatible with them. There are three ways to deal with this situation:
#. Provide new values for all incompatible interfaces, for example::
openstack baremetal node set test --driver ipmi \
baremetal node set test --driver ipmi \
--boot-interface pxe \
--deploy-interface iscsi \
--management-interface ipmitool \
@ -83,7 +83,7 @@ not compatible with them. There are three ways to deal with this situation:
#. Request resetting some of the interfaces to their new defaults by using the
``--reset-<IFACE>-interface`` family of arguments, for example::
openstack baremetal node set test --driver ipmi \
baremetal node set test --driver ipmi \
--reset-boot-interface \
--reset-deploy-interface \
--reset-management-interface \
@ -94,11 +94,11 @@ not compatible with them. There are three ways to deal with this situation:
#. Request resetting all interfaces to their new defaults::
openstack baremetal node set test --driver ipmi --reset-interfaces
baremetal node set test --driver ipmi --reset-interfaces
You can still specify explicit values for some interfaces::
openstack baremetal node set test --driver ipmi --reset-interfaces \
baremetal node set test --driver ipmi --reset-interfaces \
--deploy-interface direct
.. note:: This feature is available starting with ironic 11.1.0 (Rocky
@ -137,7 +137,7 @@ For example, in case of the :ref:`pxe-boot`:
#. Change the node to use the ``noop`` management interface::
openstack baremetal node set <NODE> --management-interface noop
baremetal node set <NODE> --management-interface noop
Unsupported drivers
-------------------

4
doc/source/admin/drivers/ansible.rst

@ -188,12 +188,12 @@ configuration file, for their descriptions and default values please see
Driver properties for the Node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Set them per-node via ``openstack baremetal node set`` command,
Set them per-node via ``baremetal node set`` command,
for example:
.. code-block:: shell
openstack baremetal node set <node> \
baremetal node set <node> \
--deploy-interface ansible \
--driver-info ansible_username=stack \
--driver-info ansible_key_file=/etc/ironic/id_rsa

4
doc/source/admin/drivers/ibmc.rst

@ -86,12 +86,12 @@ field:
verification. To disable verifying TLS_, set this
to False. This is optional.
The ``openstack baremetal node create`` command can be used to enroll
The ``baremetal node create`` command can be used to enroll
a node with the ``ibmc`` driver. For example:
.. code-block:: bash
openstack baremetal node create --driver ibmc
baremetal node create --driver ibmc
--driver-info ibmc_address=https://example.com \
--driver-info ibmc_username=admin \
--driver-info ibmc_password=password

32
doc/source/admin/drivers/idrac.rst

@ -159,7 +159,7 @@ hardware type using WSMAN for all interfaces:
.. code-block:: bash
openstack baremetal node create --driver idrac \
baremetal node create --driver idrac \
--driver-info drac_username=user \
--driver-info drac_password=pa$$w0rd \
--driver-info drac_address=drac.host
@ -169,7 +169,7 @@ hardware type using Redfish for all interfaces:
.. code-block:: bash
openstack baremetal node create --driver idrac \
baremetal node create --driver idrac \
--driver-info redfish_username=user \
--driver-info redfish_password=pa$$w0rd \
--driver-info redfish_address=drac.host \
@ -186,7 +186,7 @@ hardware type assuming a mix of Redfish and WSMAN interfaces are used:
.. code-block:: bash
openstack baremetal node create --driver idrac \
baremetal node create --driver idrac \
--driver-info drac_username=user \
--driver-info drac_password=pa$$w0rd
--driver-info drac_address=drac.host \
@ -360,7 +360,7 @@ hot spare physical disks, and clears foreign configuration:
.. code-block:: bash
openstack baremetal node clean --clean-steps \
baremetal node clean --clean-steps \
'[{"interface": "raid", "step": "delete_configuration"}]' ${node_uuid}
@ -369,7 +369,7 @@ configuration:
.. code-block:: bash
openstack baremetal node set --target-raid-config '{ "logical_disks":
baremetal node set --target-raid-config '{ "logical_disks":
[ { "controller": "RAID.Integrated.1-1",
"is_root_volume": true,
"physical_disks": [
@ -459,7 +459,7 @@ Get BIOS Config
.. code-block:: bash
openstack baremetal node passthru call --http-method GET ${node_uuid} get_bios_config
baremetal node passthru call --http-method GET ${node_uuid} get_bios_config
Snippet of output showing virtualization enabled:
@ -491,7 +491,7 @@ Set BIOS Config
.. code-block:: bash
openstack baremetal node passthru call ${node_uuid} set_bios_config --arg "name=value"
baremetal node passthru call ${node_uuid} set_bios_config --arg "name=value"
Walkthrough of perfoming a BIOS configuration change:
@ -505,7 +505,7 @@ two properties that are being changed are:
.. code-block:: bash
openstack baremetal node passthru call ${node_uuid} set_bios_config \
baremetal node passthru call ${node_uuid} set_bios_config \
--arg "ProcVirtualization=Enabled" \
--arg "SriovGlobalEnable=Enabled"
@ -532,7 +532,7 @@ Ironic power API.
.. code-block:: bash
openstack baremetal node passthru call ${node_uuid} commit_bios_config \
baremetal node passthru call ${node_uuid} commit_bios_config \
--arg "reboot=true"
.. code-block:: json
@ -546,7 +546,7 @@ The state of any executing job can be queried:
.. code-block:: bash
openstack baremetal node passthru call --http-method GET ${node_uuid} list_unfinished_jobs
baremetal node passthru call --http-method GET ${node_uuid} list_unfinished_jobs
.. code-block:: json
@ -568,7 +568,7 @@ Instead of committing, a pending change can be abandoned:
.. code-block:: bash
openstack baremetal node passthru call --http-method DELETE ${node_uuid} abandon_bios_config
baremetal node passthru call --http-method DELETE ${node_uuid} abandon_bios_config
The abandon command does not provide a response body.
@ -609,18 +609,18 @@ The boot mode can be changed via the vendor passthru interface as follows:
.. code-block:: bash
openstack baremetal node passthru call ${node_uuid} set_bios_config \
baremetal node passthru call ${node_uuid} set_bios_config \
--arg "BootMode=Uefi"
openstack baremetal node passthru call ${node_uuid} commit_bios_config \
baremetal node passthru call ${node_uuid} commit_bios_config \
--arg "reboot=true"
.. code-block:: bash
openstack baremetal node passthru call ${node_uuid} set_bios_config \
baremetal node passthru call ${node_uuid} set_bios_config \
--arg "BootMode=Bios"
openstack baremetal node passthru call ${node_uuid} commit_bios_config \
baremetal node passthru call ${node_uuid} commit_bios_config \
--arg "reboot=true"
Known Issues
@ -661,7 +661,7 @@ time as waiting for iDRAC to become ready again and then time out, for example:
.. code-block:: bash
openstack baremetal node passthru call --http-method GET \
baremetal node passthru call --http-method GET \
aed58dca-1b25-409a-a32f-3a817d59e1e0 list_unfinished_jobs
Timed out waiting for a reply to message ID 547ce7995342418c99ef1ea4a0054572 (HTTP 500)

26
doc/source/admin/drivers/ilo.rst

@ -235,7 +235,7 @@ The following command can be used to enroll a ProLiant node with
.. code-block:: console
openstack baremetal node create --os-baremetal-api-version=1.38 \
baremetal node create --os-baremetal-api-version=1.38 \
--driver ilo \
--deploy-interface direct \
--raid-interface agent \
@ -251,7 +251,7 @@ The following command can be used to enroll a ProLiant node with
.. code-block:: console
openstack baremetal node create \
baremetal node create \
--driver ilo5 \
--deploy-interface direct \
--raid-interface ilo5 \
@ -547,7 +547,7 @@ of boot mode (Legacy BIOS or UEFI).
To configure a node in ``uefi`` mode, then set ``capabilities`` as below::
openstack baremetal node set <node-uuid> --property capabilities='boot_mode:uefi'
baremetal node set <node-uuid> --property capabilities='boot_mode:uefi'
Nodes having ``boot_mode`` set to ``uefi`` may be requested by adding an
``extra_spec`` to the nova flavor::
@ -593,7 +593,7 @@ The UEFI secure boot can be configured in ironic by adding
To enable ``secure_boot`` on a node add it to ``capabilities`` as below::
openstack baremetal node set <node-uuid> --property capabilities='secure_boot:true'
baremetal node set <node-uuid> --property capabilities='secure_boot:true'
Alternatively see `Hardware Inspection Support`_ to know how to
automatically populate the secure boot capability.
@ -847,7 +847,7 @@ Create a deploy template with a single step:
.. code-block:: console
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_HYPERTHREADING_ON \
--steps '[{"interface": "bios", "step": "apply_configuration", "args": {"settings": [{"name": "ProcHyperthreading", "value": "Enabled"}]}, "priority": 150}]'
@ -855,7 +855,7 @@ Add the trait ``CUSTOM_HYPERTHREADING_ON`` to the node represented by ``$node_id
.. code-block:: console
openstack baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_ON
baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_ON
Update the flavor ``bm-hyperthreading-on`` in the Compute service with the
following property:
@ -1974,7 +1974,7 @@ NMI on a server:
.. code-block:: console
openstack baremetal node inject nmi <node>
baremetal node inject nmi <node>
Following command can be used to inject NMI via Compute service:
@ -1993,10 +1993,10 @@ soft power operations on a server:
.. code-block:: console
openstack baremetal node reboot --soft \
baremetal node reboot --soft \
[--power-timeout <power-timeout>] <node>
openstack baremetal node power off --soft \
baremetal node power off --soft \
[--power-timeout <power-timeout>] <node>
.. note::
@ -2046,7 +2046,7 @@ into the baremetal service using the iLO IPv6 addresses.
.. code-block:: console
openstack baremetal node create --driver ilo --deploy-interface direct \
baremetal node create --driver ilo --deploy-interface direct \
--driver-info ilo_address=2001:0db8:85a3:0000:0000:8a2e:0370:7334 \
--driver-info ilo_username=test-user \
--driver-info ilo_password=test-password \
@ -2096,7 +2096,7 @@ Below are the steps to perform this clean step:
.. code-block:: console
openstack baremetal node clean $node_ident --clean-steps\
baremetal node clean $node_ident --clean-steps\
'[{"interface": "management", "step": "one_button_secure_erase"}]'
* Once the clean step would triggered and node go to 'clean wait' state and
@ -2104,7 +2104,7 @@ Below are the steps to perform this clean step:
.. code-block:: console
openstack baremetal node delete $node_ident
baremetal node delete $node_ident
.. note::
* Even after deleting the node, One Button Secure Erase operation would continue
@ -2147,7 +2147,7 @@ and ``ilo-uefi-https`` boot interface:
.. code-block:: console
openstack baremetal node create \
baremetal node create \
--driver ilo5 \
--boot-interface ilo-uefi-https \
--deploy-interface direct \

12
doc/source/admin/drivers/intel-ipmi.rst

@ -73,10 +73,10 @@ All the configuration value required for IntelIPMI is the same as the IPMI
hardware type except the management interface which is ``intel-ipmitool``.
Refer :doc:`ipmitool` for details.
The ``openstack baremetal node create`` command can be used to enroll a node
The ``baremetal node create`` command can be used to enroll a node
with an IntelIPMI driver. For example::
openstack baremetal node create --driver intel-ipmi \
baremetal node create --driver intel-ipmi \
--driver-info ipmi_address=<address> \
--driver-info ipmi_username=<username> \
--driver-info ipmi_password=<password>
@ -119,15 +119,15 @@ templates for each profiles in Ironic.
.. code-block:: console
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_BASE \
--steps '[{"interface": "management", "step": "configure_intel_speedselect", "args": {"intel_speedselect_config": "0x00", "socket_count": 2}, "priority": 150}]'
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_1 \
--steps '[{"interface": "management", "step": "configure_intel_speedselect", "args": {"intel_speedselect_config": "0x01", "socket_count": 2}, "priority": 150}]'
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_2 \
--steps '[{"interface": "management", "step": "configure_intel_speedselect", "args": {"intel_speedselect_config": "0x02", "socket_count": 2}, "priority": 150}]'
@ -136,7 +136,7 @@ All Intel SST-PP capable nodes should have these traits associated.
.. code-block:: console
openstack baremetal node add trait node-0 \
baremetal node add trait node-0 \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_BASE \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_1 \
CUSTOM_INTEL_SPEED_SELECT_CONFIG_2

2
doc/source/admin/drivers/ipa.rst

@ -119,4 +119,4 @@ that, you have to update the node's ``driver_info`` field and set the
``deploy_forces_oob_reboot`` parameter with the value of **True**. For
example, the below command sets this configuration in a specific node::
openstack baremetal node set <UUID or name> --driver-info deploy_forces_oob_reboot=True
baremetal node set <UUID or name> --driver-info deploy_forces_oob_reboot=True

16
doc/source/admin/drivers/ipmitool.rst

@ -74,10 +74,10 @@ good practice to have them set:
It is highly recommend that you setup a username and password for
your BMC.
The ``openstack baremetal node create`` command can be used to enroll a node
The ``baremetal node create`` command can be used to enroll a node
with an IPMItool-based driver. For example::
openstack baremetal node create --driver ipmi \
baremetal node create --driver ipmi \
--driver-info ipmi_address=<address> \
--driver-info ipmi_username=<username> \
--driver-info ipmi_password=<password>
@ -125,13 +125,13 @@ The parameter ``ipmi_bridging`` should specify the type of bridging
required: *single* or *dual* to access the bare metal node. If the
parameter is not specified, the default value will be set to *no*.
The ``openstack baremetal node set`` command can be used to set the required
The ``baremetal node set`` command can be used to set the required
bridging information to the Ironic node enrolled with the IPMItool
driver. For example:
* Single Bridging::
openstack baremetal node set <UUID or name> \
baremetal node set <UUID or name> \
--driver-info ipmi_local_address=<address> \
--driver-info ipmi_bridging=single \
--driver-info ipmi_target_channel=<channel> \
@ -139,7 +139,7 @@ driver. For example:
* Double Bridging::
openstack baremetal node set <UUID or name> \
baremetal node set <UUID or name> \
--driver-info ipmi_local_address=<address> \
--driver-info ipmi_bridging=dual \
--driver-info ipmi_transit_channel=<transit channel> \
@ -159,10 +159,10 @@ the following option needs to be set to the node's ``driver_info`` field:
- ``ipmi_protocol_version``: The version of the IPMI protocol; default
is *2.0*. Supported values are *1.5* or *2.0*.
The ``openstack baremetal node set`` command can be used to set the desired
The ``baremetal node set`` command can be used to set the desired
protocol version::
openstack baremetal node set <UUID or name> --driver-info ipmi_protocol_version=<version>
baremetal node set <UUID or name> --driver-info ipmi_protocol_version=<version>
.. warning::
Version *1.5* of the IPMI protocol does not support encryption.
@ -188,7 +188,7 @@ Another possible problem is ``ipmitool`` commands taking very long (tens of
seconds or even minutes) because the BMC does not support cipher suite
negotiation. In both cases you can specify the required suite yourself, e.g.::
openstack baremetal node set <UUID or name> --driver-info ipmi_cipher_suite=3
baremetal node set <UUID or name> --driver-info ipmi_cipher_suite=3
Static boot order configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

12
doc/source/admin/drivers/irmc.rst

@ -203,7 +203,7 @@ following sections describe both methods:
To enable secure boot we need to set a capability on the bare metal node
and the bare metal flavor, for example::
openstack baremetal node set <node-uuid> --property capabilities='secure_boot:true'
baremetal node set <node-uuid> --property capabilities='secure_boot:true'
openstack flavor set FLAVOR-NAME --property capabilities:secure_boot="true"
* Enabling secure boot without Compute service:
@ -211,7 +211,7 @@ following sections describe both methods:
scheduler to perform more advanced scheduling of instances, we need
to enable secure boot without nova, for example::
openstack baremetal node set <node-uuid> --instance-info capabilities='{"secure_boot": "true"}'
baremetal node set <node-uuid> --instance-info capabilities='{"secure_boot": "true"}'
.. _irmc_node_cleaning:
@ -287,7 +287,7 @@ the iRMC driver requires the following configuration:
It can be set with the following command::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--driver-info irmc_pci_physical_ids={} \
--driver-info irmc_pci_physical_ids/$PORT_UUID=LAN0-1 \
--driver-info irmc_pci_physical_ids/$VOLUME_CONNECTOR_UUID=CNA1-1
@ -301,7 +301,7 @@ the iRMC driver requires the following configuration:
For example, if the storage network is 10.2.0.0/22, use the following
command::
openstack baremetal node set $NODE_UUID --driver-info irmc_storage_network_size=22
baremetal node set $NODE_UUID --driver-info irmc_storage_network_size=22
Supported hardware
~~~~~~~~~~~~~~~~~~
@ -402,7 +402,7 @@ See :ref:`capabilities-discovery` for more details and examples.
The operator can add a trait in compute service flavor, for example::
openstack baremetal node add trait $NODE_UUID CUSTOM_CPU_FPGA
baremetal node add trait $NODE_UUID CUSTOM_CPU_FPGA
A valid trait must be no longer than 255 characters. Standard traits are
defined in the os_traits library. A custom trait must start with the prefix
@ -430,7 +430,7 @@ configuration:
* It is necessary to set ironic configuration into Node with
JSON file option::
$ openstack baremetal node set <node-uuid-or-name> \
$ baremetal node set <node-uuid-or-name> \
--target-raid-config <JSON file containing target RAID configuration>
Here is some sample values for JSON file::

16
doc/source/admin/drivers/redfish.rst

@ -90,12 +90,12 @@ field:
as ``[redfish]auth_type``.
The ``openstack baremetal node create`` command can be used to enroll
The ``baremetal node create`` command can be used to enroll
a node with the ``redfish`` driver. For example:
.. code-block:: bash
openstack baremetal node create --driver redfish --driver-info \
baremetal node create --driver redfish --driver-info \
redfish_address=https://example.com --driver-info \
redfish_system_id=/redfish/v1/Systems/CX34R87 --driver-info \
redfish_username=admin --driver-info redfish_password=password \
@ -164,7 +164,7 @@ BIOS boot mode, it suffice to set ironic boot interface to
.. code-block:: bash
openstack baremetal node set --boot-interface redfish-virtual-media node-0
baremetal node set --boot-interface redfish-virtual-media node-0
If UEFI boot mode is desired, the user should additionally supply EFI
System Partition image (ESP_) via ``[driver-info]/bootloader`` ironic node
@ -172,7 +172,7 @@ property or ironic configuration file in form of Glance image UUID or a URL.
.. code-block:: bash
openstack baremetal node set --driver-info bootloader=<glance-uuid> node-0
baremetal node set --driver-info bootloader=<glance-uuid> node-0
If ``[driver_info]/config_via_floppy`` boolean property of the node is set to
``true``, ironic will create a file with runtime configuration parameters,
@ -201,7 +201,7 @@ of ``ACTIVE``.
.. code-block:: bash
openstack baremetal node set \
baremetal node set \
--instance_info boot_iso=http://url/to.iso node-0
This initial interface does not support bootloader configuration
@ -242,7 +242,7 @@ the configuration generated by the Network service.
.. code-block:: bash
openstack baremetal node set \
baremetal node set \
--network-data ~/network_data.json <node>
Node-based configuration can be useful in standalone ironic deployment
@ -365,11 +365,11 @@ Finally, launch the firmware update cleaning step against the node. The
following example assumes the above JSON is in a file named
``firmware_update.json``::
openstack baremetal node clean <ironic_node_uuid> --clean-steps firmware_update.json
baremetal node clean <ironic_node_uuid> --clean-steps firmware_update.json
In the following example, the JSON is specified directly on the command line::
openstack baremetal node clean <ironic_node_uuid> --clean-steps '[{"interface": "management", "step": "update_firmware", "args": {"firmware_images":[{"url": "http://192.0.2.10/BMC_4_22_00_00.EXE", "wait": 300}, {"url": "https://192.0.2.10/NIC_19.0.12_A00.EXE"}]}}]'
baremetal node clean <ironic_node_uuid> --clean-steps '[{"interface": "management", "step": "update_firmware", "args": {"firmware_images":[{"url": "http://192.0.2.10/BMC_4_22_00_00.EXE", "wait": 300}, {"url": "https://192.0.2.10/NIC_19.0.12_A00.EXE"}]}}]'
.. note::
Firmware updates may take some time to complete. If a firmware update

4
doc/source/admin/drivers/snmp.rst

@ -98,7 +98,7 @@ Enabling the SNMP Hardware Type
.. code-block:: console
openstack baremetal node set --property capabilities="boot_option:netboot" <node-uuid>
baremetal node set --property capabilities="boot_option:netboot" <node-uuid>
openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor
@ -161,7 +161,7 @@ type:
.. code-block:: bash
openstack baremetal node create --os-baremetal-api-version=1.31 \
baremetal node create --os-baremetal-api-version=1.31 \
--driver snmp --driver-info snmp_driver=<pdu_manufacturer> \
--driver-info snmp_address=<ip_address> \
--driver-info snmp_outlet=<outlet_index> \

4
doc/source/admin/drivers/xclarity.rst

@ -55,12 +55,12 @@ field and are required:
xclarity_username to the XClarity Controller.
- ``xclarity_hardware_id``: The hardware ID of the XClarity managed server.
The ``openstack baremetal node create`` command can be used to enroll
The ``baremetal node create`` command can be used to enroll
a node with the ``xclarity`` driver. For example:
.. code-block:: bash
openstack baremetal node create --driver xclarity \
baremetal node create --driver xclarity \
--driver-info xclarity_manager_ip=https://10.240.217.101 \
--driver-info xclarity_username=admin \
--driver-info xclarity_password=password \

4
doc/source/admin/inspection.rst

@ -25,11 +25,11 @@ 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>
baremetal node manage <node_UUID>
Then inspection can be initiated using the following command::
openstack baremetal node inspect <node_UUID>
baremetal node inspect <node_UUID>
.. _capabilities-discovery:

2
doc/source/admin/interfaces/boot.rst

@ -49,7 +49,7 @@ costly than a non-persistent one, so this can bring performance improvements.
Set the flag ``force_persistent_boot_device`` to ``True`` in the node's
``driver_info``::
$ openstack baremetal node set --driver-info force_persistent_boot_device=True <node>
$ baremetal node set --driver-info force_persistent_boot_device=True <node>
.. note::
It's recommended to check if the node's state has not changed as there

16
doc/source/admin/interfaces/deploy.rst

@ -20,8 +20,8 @@ This interface is used by default, if enabled (see
:ref:`enable-hardware-interfaces`). You can specify it explicitly
when creating or updating a node::
openstack baremetal node create --driver ipmi --deploy-interface iscsi
openstack baremetal node set <NODE> --deploy-interface iscsi
baremetal node create --driver ipmi --deploy-interface iscsi
baremetal node set <NODE> --deploy-interface iscsi
.. _iSCSI: https://en.wikipedia.org/wiki/ISCSI
@ -38,8 +38,8 @@ a detailed explanation of how this deploy interface works.
You can specify this deploy interface when creating or updating a node::
openstack baremetal node create --driver ipmi --deploy-interface direct
openstack baremetal node set <NODE> --deploy-interface direct
baremetal node create --driver ipmi --deploy-interface direct
baremetal node set <NODE> --deploy-interface direct
.. note::
For historical reasons the ``direct`` deploy interface is sometimes called
@ -74,11 +74,11 @@ This configuration affects *glance* and ``file://`` images. If you want
.. note::
This option can also be set per node in ``driver_info``::
openstack baremetal node set <node> --driver-info image_download_source=local
baremetal node set <node> --driver-info image_download_source=local
or per instance in ``instance_info``::
openstack baremetal node set <node> --instance-info image_download_source=local
baremetal node set <node> --instance-info image_download_source=local
You need to set up a workable HTTP server at each conductor node which with
``direct`` deploy interface enabled, and check http related options in the
@ -127,8 +127,8 @@ a node:
.. code-block:: shell
openstack baremetal node create --driver ipmi --deploy-interface ansible
openstack baremetal node set <NODE> --deploy-interface ansible
baremetal node create --driver ipmi --deploy-interface ansible
baremetal node set <NODE> --deploy-interface ansible
For more information about this deploy interface, its features and how to use
it, see :doc:`Ansible deploy interface <../drivers/ansible>`.

12
doc/source/admin/multitenancy.rst

@ -135,7 +135,7 @@ Configuring nodes
ironic-conductor's configuration file. Set it to ``neutron`` to use the
Networking service's ML2 driver::
openstack baremetal node create --network-interface neutron --driver ipmi
baremetal node create --network-interface neutron --driver ipmi
.. note::
If the ``[DEFAULT]/default_network_interface`` configuration option is
@ -145,12 +145,12 @@ Configuring nodes
#. To update an existing node's network interface to ``neutron``, use the
following commands::
openstack baremetal node set $NODE_UUID_OR_NAME \
baremetal node set $NODE_UUID_OR_NAME \
--network-interface neutron
#. Create a port as follows::
openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
--local-link-connection switch_id=$SWITCH_MAC_ADDRESS \
--local-link-connection switch_info=$SWITCH_HOSTNAME \
--local-link-connection port_id=$SWITCH_PORT \
@ -169,14 +169,14 @@ Configuring nodes
the port GUID's lower 3 and higher 3 bytes. In this example it would be f4:52:14:38:39:81.
Putting it all together, create an Infiniband port as follows::
openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
--pxe-enabled true \
--extra client-id=$CLIENT_ID \
--physical-network physnet1
#. Create a Smart NIC port as follows::
openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
--local-link-connection hostname=$HOSTNAME \
--local-link-connection port_id=$REP_NAME \
--pxe-enabled true \
@ -188,7 +188,7 @@ Configuring nodes
#. Check the port configuration::
openstack baremetal port show $PORT_UUID
baremetal port show $PORT_UUID
After these steps, the provisioning of the created node will happen in the
provisioning network, and then the node will be moved to the tenant network

14
doc/source/admin/node-deployment.rst

@ -219,10 +219,10 @@ single step:
Further information on this API is available `here
<https://docs.openstack.org/api-ref/baremetal/index.html?expanded=create-deploy-template-detail#create-deploy-template>`__.
Creating a deploy template via "openstack baremetal" client
Creating a deploy template via "baremetal" client
-----------------------------------------------------------
A deploy template can be created via the ``openstack baremetal deploy template
A deploy template can be created via the ``baremetal deploy template
create`` command, starting with ``python-ironicclient`` 2.7.0.
The argument ``--steps`` must be specified. Its value is one of:
@ -235,7 +235,7 @@ Example of creating a deploy template with a single step using a JSON string:
.. code-block:: console
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_HYPERTHREADING_ON \
--steps '[{"interface": "bios", "step": "apply_configuration", "args": {"settings": [{"name": "LogicalProc", "value": "Enabled"}]}, "priority": 150}]'
@ -243,7 +243,7 @@ Or with a file:
.. code-block:: console
openstack baremetal deploy template create \
baremetal deploy template create \
CUSTOM_HYPERTHREADING_ON \
---steps my-deploy-steps.txt
@ -251,7 +251,7 @@ Or with stdin:
.. code-block:: console
cat my-deploy-steps.txt | openstack baremetal deploy template create \
cat my-deploy-steps.txt | baremetal deploy template create \
CUSTOM_HYPERTHREADING_ON \
--steps -
@ -265,7 +265,7 @@ to the node represented by ``$node_ident``:
.. code-block:: console
openstack baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_ON
baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_ON
We also update the flavor ``bm-hyperthreading-on`` in the Compute
service with the following property:
@ -311,7 +311,7 @@ To make this example more dynamic, let's add a second trait
.. code-block:: console
openstack baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_OFF
baremetal node add trait $node_ident CUSTOM_HYPERTHREADING_OFF
We could also update a second flavor, ``bm-hyperthreading-off``, with the
following property:

4
doc/source/admin/node-multitenancy.rst

@ -16,8 +16,8 @@ Setting the Owner and Lessee
Non-administrative access to a node is controlled through a node's ``owner``
or ``lessee`` attribute::
openstack baremetal node set --owner 080925ee2f464a2c9dce91ee6ea354e2 node-7
openstack baremetal node set --lessee 2a210e5ff114c8f2b6e994218f51a904 node-10
baremetal node set --owner 080925ee2f464a2c9dce91ee6ea354e2 node-7
baremetal node set --lessee 2a210e5ff114c8f2b6e994218f51a904 node-10
Configuring the Bare Metal Service Policy

14
doc/source/admin/raid.rst

@ -27,7 +27,7 @@ Ironic Python Agent ramdisk. For in-band hardware RAID configuration,
a hardware manager which supports RAID should be bundled with the ramdisk.
Whether a node supports RAID configuration could be found using the CLI
command ``openstack baremetal node validate <node-uuid>``. In-band RAID is
command ``baremetal node validate <node-uuid>``. In-band RAID is
usually implemented by the ``agent`` RAID interface.
Build agent ramdisk which supports RAID configuration
@ -74,7 +74,7 @@ done on the node.
Each dictionary of logical disk contains the desired properties of logical
disk supported by the hardware type. These properties are discoverable by::
openstack baremetal driver raid property list <driver name>
baremetal driver raid property list <driver name>
Mandatory properties
^^^^^^^^^^^^^^^^^^^^
@ -296,7 +296,7 @@ physical disk found on the bare metal node.
To get the current RAID configuration::
openstack baremetal node show <node-uuid-or-name>
baremetal node show <node-uuid-or-name>
Workflow
========
@ -314,12 +314,12 @@ Workflow
`Target RAID configuration`_. The target RAID configuration is set on
the Ironic node::
openstack baremetal node set <node-uuid-or-name> \
baremetal node set <node-uuid-or-name> \
--target-raid-config <JSON file containing target RAID configuration>
The CLI command can accept the input from standard input also::
openstack baremetal node set <node-uuid-or-name> \
baremetal node set <node-uuid-or-name> \
--target-raid-config -
* Create a JSON file with the RAID clean steps for manual cleaning. Add other
@ -343,13 +343,13 @@ Workflow
* Bring the node to ``manageable`` state and do a ``clean`` action to start
cleaning on the node::
openstack baremetal node clean <node-uuid-or-name> \
baremetal node clean <node-uuid-or-name> \
--clean-steps <JSON file containing clean steps created above>
* After manual cleaning is complete, the current RAID configuration is
reported in the ``raid_config`` field when running::
openstack baremetal node show <node-uuid-or-name>
baremetal node show <node-uuid-or-name>
Software RAID
=============

10
doc/source/admin/ramdisk-boot.rst

@ -26,7 +26,7 @@ be set upon creation of a new node:
.. code-block:: shell
openstack baremetal node create --driver ipmi \
baremetal node create --driver ipmi \
--deploy-interface ramdisk \
--boot-interface ipxe
@ -34,13 +34,13 @@ or update an existing node:
.. code-block:: shell
openstack baremetal node set <NODE> --deploy-interface ramdisk
baremetal node set <NODE> --deploy-interface ramdisk
Using virtual media:
.. code-block:: shell
openstack baremetal node create --driver redfish \
baremetal node create --driver redfish \
--deploy-interface ramdisk \
--boot-interface redfish-virtual-media
@ -54,9 +54,9 @@ For example,
.. code-block:: shell
openstack baremetal node set <NODE> \
baremetal node set <NODE> \
--instance-info boot_iso=http://path/to/boot.iso
openstack baremetal node deploy <NODE>
baremetal node deploy <NODE>
Limitations
-----------

6
doc/source/admin/rescue.rst

@ -62,7 +62,7 @@ but an example of how to do this is outlined below:
.. code-block:: console
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--driver-info rescue_ramdisk=$RESCUE_INITRD_UUID \
--driver-info rescue_kernel=$RESCUE_VMLINUZ_UUID
@ -76,7 +76,7 @@ using ssh, as given below:
.. code-block:: console
openstack baremetal node rescue $NODE_UUID \
baremetal node rescue $NODE_UUID \
--rescue-password <PASSWORD> --wait
ssh rescue@$INSTANCE_IP_ADDRESS
@ -87,7 +87,7 @@ before proceeding with unrescue. The node unrescue can be done as given below:
.. code-block:: console
openstack baremetal node unrescue $NODE_UUID
baremetal node unrescue $NODE_UUID
``rescue`` and ``unrescue`` operations can also be triggered via the Compute
Service using the following commands:

8
doc/source/admin/retirement.rst

@ -29,7 +29,7 @@ How to use
When it is known that a node shall be retired, set the ``retired``
flag on the node with::
openstack baremetal node set --retired node-001
baremetal node set --retired node-001
This can be done irrespective of the state the node is in, so in
particular while the node is ``active``.
@ -42,7 +42,7 @@ particular while the node is ``active``.
Optionally, a reason can be specified when a node is retired, e.g.::
openstack baremetal node set --retired node-001 \
baremetal node set --retired node-001 \
--retired-reason "End of warranty for delivery abc123"
Upon instance deletion, an ``active`` node with the ``retired`` flag
@ -55,10 +55,10 @@ accidental re-use of nodes tagged for removal from the fleet. In order
to move these nodes to ``available`` none the less, the ``retired`` field
needs to be removed first. This can be done via::
openstack baremetal node unset --retired node-001
baremetal node unset --retired node-001
In order to facilitate the identification of nodes marked for retirement,
e.g. by other teams, ironic also allows to list all nodes which have the
``retired`` flag set::
openstack baremetal node list --retired
baremetal node list --retired

16
doc/source/admin/troubleshooting.rst

@ -24,25 +24,25 @@ A few things should be checked in this case:
maintenance mode and not already used by an existing instance.
Check with the following command::
openstack baremetal node list --provision-state available --no-maintenance --unassociated
baremetal node list --provision-state available --no-maintenance --unassociated
If this command does not show enough nodes, use generic ``openstack baremetal
If this command does not show enough nodes, use generic ``baremetal
node list`` to check other nodes. For example, nodes in ``manageable`` state
should be made available::
openstack baremetal node provide <IRONIC NODE>
baremetal node provide <IRONIC NODE>
The Bare metal service automatically puts a node in maintenance mode if
there are issues with accessing its management interface. Check the power
credentials (e.g. ``ipmi_address``, ``ipmi_username`` and ``ipmi_password``)
and then move the node out of maintenance mode::
openstack baremetal node maintenance unset <IRONIC NODE>
baremetal node maintenance unset <IRONIC NODE>
The ``node validate`` command can be used to verify that all required fields
are present. The following command should not return anything::
openstack baremetal node validate <IRONIC NODE> | grep -E '(power|management)\W*False'
baremetal node validate <IRONIC NODE> | grep -E '(power|management)\W*False'
Maintenance mode will be also set on a node if automated cleaning has
failed for it previously.
@ -113,7 +113,7 @@ A few things should be checked in this case:
JSON field has valid values for the keys ``cpus``, ``cpu_arch``,
``memory_mb`` and ``local_gb``. Example of valid properties::
$ openstack baremetal node show <IRONIC NODE> --fields properties
$ baremetal node show <IRONIC NODE> --fields properties
+------------+------------------------------------------------------------------------------------+
| Property | Value |
+------------+------------------------------------------------------------------------------------+
@ -146,7 +146,7 @@ A few things should be checked in this case:
But in Ironic node::
$ openstack baremetal node show <IRONIC NODE> --fields properties
$ baremetal node show <IRONIC NODE> --fields properties
+------------+-----------------------------------------+
| Property | Value |
+------------+-----------------------------------------+