openstack/ironic
Code Issues Proposed changes

Merge "Update .rst files"

Browse Source
This commit is contained in:
Zuul 2020-10-22 08:46:45 +00:00 committed by Gerrit Code Review
commit 219d72543c
17 changed files with 59 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -180,7 +180,7 @@ upon what driver is selected for the node.
Any node that is in the ``adopt failed`` state can have the ``adopt`` verb
re-attempted. Example::
openstack baremetal node adopt <node name or uuid>
baremetal node adopt <node name or uuid>
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

4
doc/source/admin/bios.rst
View File

@ -51,7 +51,7 @@ Retrieve BIOS settings
To retrieve the cached BIOS configuration from a specified node::
$ baremetal node bios setting list <node-uuid>
$ baremetal node bios setting list <node>
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::
$ baremetal node bios setting show <node-uuid> <setting-name>
$ baremetal node bios setting show <node> <setting-name>
If ``-f json`` is added as suffix to above command, it returns BIOS settings
as following::

10
doc/source/admin/boot-from-volume.rst
View File

@ -53,8 +53,7 @@ You will need to specify what storage interface the node will use to handle
storage operations. For example, to set the storage interface to ``cinder``
on an existing node::
openstack --os-baremetal-api-version 1.33 baremetal node set \
--storage-interface cinder $NODE_UUID
baremetal node set --storage-interface cinder $NODE_UUID
A default storage interface can be specified in ironic.conf. See the
`Conductor Configuration`_ section for details.
@ -65,15 +64,14 @@ In order for a bare metal node to boot from an iSCSI volume, the ``iscsi_boot``
capability for the node must be set to ``True``. For example, if you want to
update an existing node to boot from volume::
openstack --os-baremetal-api-version 1.33 baremetal node set \
--property capabilities=iscsi_boot:True $NODE_UUID
baremetal node set --property capabilities=iscsi_boot:True $NODE_UUID
You will also need to create a volume connector for the node, so the storage
interface will know how to communicate with the node for storage operation. In
the case of iSCSI, you will need to provide an iSCSI Qualifying Name (IQN)
that is unique to your SAN. For example, to create a volume connector for iSCSI::
openstack --os-baremetal-api-version 1.33 baremetal volume connector create \
baremetal volume connector create \
--node $NODE_UUID --type iqn --connector-id iqn.2017-08.org.openstack.$NODE_UUID
Image Creation
@ -115,7 +113,7 @@ it is not explicitly required, and can be performed manually.
A target record can be created using a command similar to the example below::
openstack --os-baremetal-api-version 1.33 baremetal volume target create \
baremetal volume target create \
--node $NODE_UUID --type iscsi --boot-index 0 --volume $VOLUME_UUID
.. Note:: A ``boot-index`` value of ``0`` represents the boot volume for a

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

@ -119,23 +119,22 @@ The web console can be configured in Bare Metal service in the following way:
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
baremetal node set <node> --console-interface ipmitool-shellinabox
Enable the web console, for example::
baremetal node set <node-uuid> \
baremetal node set <node> \
--driver-info <terminal_port>=<customized_port>
baremetal node console enable <node-uuid>
baremetal node console enable <node>
Check whether the console is enabled, for example::
baremetal node validate <node-uuid>
baremetal node validate <node>
Disable the web console, for example::
baremetal node console disable <node-uuid>
baremetal node unset <node-uuid> --driver-info <terminal_port>
baremetal node console disable <node>
baremetal node unset <node> --driver-info <terminal_port>
The ``<terminal_port>`` is driver dependent. The actual name of this field can be
checked in driver properties, for example::
@ -148,7 +147,7 @@ The web console can be configured in Bare Metal service in the following way:
Get web console information for a node as follows::
baremetal node console show <node-uuid>
baremetal node console show <node>
+-----------------+----------------------------------------------------------------------+
| Property | Value |
+-----------------+----------------------------------------------------------------------+
@ -206,27 +205,26 @@ Serial consoles can be configured in the Bare Metal service as follows:
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
baremetal node set <node> --console-interface ipmitool-socat
Enable the serial console, for example::
baremetal node set <node-uuid> --driver-info ipmi_terminal_port=<port>
baremetal node console enable <node-uuid>
baremetal node set <node> --driver-info ipmi_terminal_port=<port>
baremetal node console enable <node>
Check whether the serial console is enabled, for example::
baremetal node validate <node-uuid>
baremetal node validate <node>
Disable the serial console, for example::
baremetal node console disable <node-uuid>
baremetal node unset <node-uuid> --driver-info <ipmi_terminal_port>
baremetal node console disable <node>
baremetal node unset <node> --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::
baremetal node console show <node-uuid>
baremetal node console show <node>
+-----------------+----------------------------------------------------------------------+
| Property | Value |
+-----------------+----------------------------------------------------------------------+

2
doc/source/admin/drivers.rst
View File

@ -34,7 +34,7 @@ Hardware types and interfaces are enabled in the configuration as described in
:doc:`/install/enabling-drivers`. Usually, a hardware type is configured on
enrolling as described in :doc:`/install/enrollment`::
openstack baremetal node create --driver <hardware type>
baremetal node create --driver <hardware type>
Any hardware interfaces can be specified on enrollment as well::

2
doc/source/admin/drivers/idrac.rst
View File

@ -383,7 +383,7 @@ The following command can be used to create a RAID configuration:
.. code-block:: bash
openstack baremetal node clean --clean-steps \
baremetal node clean --clean-steps \
'[{"interface": "raid", "step": "create_configuration"}]' ${node_uuid}

12
doc/source/admin/drivers/ilo.rst
View File

@ -235,7 +235,7 @@ The following command can be used to enroll a ProLiant node with
.. code-block:: console
baremetal node create --os-baremetal-api-version=1.38 \
baremetal node create \
--driver ilo \
--deploy-interface direct \
--raid-interface agent \
@ -547,7 +547,7 @@ of boot mode (Legacy BIOS or UEFI).
To configure a node in ``uefi`` mode, then set ``capabilities`` as below::
baremetal node set <node-uuid> --property capabilities='boot_mode:uefi'
baremetal node set <node> --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::
baremetal node set <node-uuid> --property capabilities='secure_boot:true'
baremetal node set <node> --property capabilities='secure_boot:true'
Alternatively see `Hardware Inspection Support`_ to know how to
automatically populate the secure boot capability.
@ -1640,9 +1640,9 @@ returns the SUM log files. The log files include ``hpsum_log.txt`` and
firmware version for each component and their update status. The log object
will be named with the following pattern::
<node-uuid>[_<instance-uuid>]_update_firmware_sum_<timestamp yyyy-mm-dd-hh-mm-ss>.tar.gz
<node>[_<instance-uuid>]_update_firmware_sum_<timestamp yyyy-mm-dd-hh-mm-ss>.tar.gz
or
<node-uuid>[_<instance-uuid>]_flash_firmware_sum_<timestamp yyyy-mm-dd-hh-mm-ss>.tar.gz
<node>[_<instance-uuid>]_flash_firmware_sum_<timestamp yyyy-mm-dd-hh-mm-ss>.tar.gz
Refer to :ref:`retrieve_deploy_ramdisk_logs` for more information on enabling and
viewing the logs returned from the ramdisk.
@ -2027,7 +2027,7 @@ Later the value of raid level of root volume can be added in
And consequently flavor needs to be updated to request the resource class
to create the server using selected node::
openstack baremetal node set test_node --resource-class \
baremetal node set test_node --resource-class \
baremetal-with-RAID10
openstack flavor set --property \

6
doc/source/admin/drivers/irmc.rst
View File

@ -101,7 +101,7 @@ Here is a command example to enroll a node with ``irmc`` hardware type.
.. code-block:: console
openstack baremetal node create \
baremetal node create \
--bios-interface irmc \
--boot-interface irmc-pxe \
--deploy-interface direct \
@ -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::
baremetal node set <node-uuid> --property capabilities='secure_boot:true'
baremetal node set <node> --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::
baremetal node set <node-uuid> --instance-info capabilities='{"secure_boot": "true"}'
baremetal node set <node> --instance-info capabilities='{"secure_boot": "true"}'
.. _irmc_node_cleaning:

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

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

2
doc/source/admin/node-deployment.rst
View File

@ -103,7 +103,7 @@ To check what deploy 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 ``deploy_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

9
doc/source/admin/portgroups.rst
View File

@ -48,12 +48,12 @@ CLI commands below specify it for completeness.
along with, optionally, its name, address, mode, properties, and if it
supports fallback to standalone ports::
openstack --os-baremetal-api-version 1.26 baremetal port group create \
baremetal port group create \
--node $NODE_UUID --name test --address fa:ab:25:48:fd:ba --mode 802.3ad \
--property miimon=100 --property xmit_hash_policy="layer2+3" \
--support-standalone-ports
A port group can also be updated with ``openstack baremetal port group set``
A port group can also be updated with ``baremetal port group set``
command, see its help for more details.
If an address is not specified, the port group address on the deployed
@ -91,13 +91,12 @@ CLI commands below specify it for completeness.
It can be done on port creation::
openstack --os-baremetal-api-version 1.26 baremetal port create \
baremetal port create \
--node $NODE_UUID --address fa:ab:25:48:fd:ba --port-group test
Or by updating an existing port::
openstack --os-baremetal-api-version 1.26 baremetal port set \
$PORT_UUID --port-group $PORT_GROUP_UUID
baremetal port set $PORT_UUID --port-group $PORT_GROUP_UUID
When updating a port, the node associated with the port has to be in
``enroll``, ``manageable``, or ``inspecting`` states. A port group can have

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

@ -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 ``baremetal node validate <node-uuid>``. In-band RAID is
command ``baremetal node validate <node>``. In-band RAID is
usually implemented by the ``agent`` RAID interface.
Build agent ramdisk which supports RAID configuration

6
doc/source/admin/troubleshooting.rst
View File

@ -66,7 +66,7 @@ A few things should be checked in this case:
#. Starting with the Pike release, check that all your nodes have the
``resource_class`` field set using the following command::
openstack --os-baremetal-api-version 1.21 baremetal node list --fields uuid name resource_class
baremetal node list --fields uuid name resource_class
Then check that the flavor(s) are configured to request these resource
classes via their properties::
@ -282,7 +282,7 @@ all the logs according to the ``deploy_logs_storage_backend``
configuration option. All log objects will be named with the following
pattern::
<node-uuid>[_<instance-uuid>]_<timestamp yyyy-mm-dd-hh:mm:ss>.tar.gz
<node>[_<instance-uuid>]_<timestamp yyyy-mm-dd-hh:mm:ss>.tar.gz
.. note::
The *instance_uuid* field is not required for deploying a node when
@ -652,7 +652,7 @@ provisioning, rescuing, or even inspection, getting the node to the
``available`` state wil unblock your delete operation, that is unless there is
a tenant VIF attahment. In that case, the vif will need to be removed from
with-in the Bare Metal service using the
``openstack baremetal node vif detach`` command.
``baremetal node vif detach`` command.
A port can also be checked to see if there is a VIF attachment by consulting
the port's ``internal_info`` field.

6
doc/source/admin/upgrade-to-hardware-types.rst
View File

@ -93,7 +93,7 @@ set new values for some or all interfaces:
export OS_BAREMETAL_API_VERSION=1.31
for uuid in $(baremetal node list --driver pxe_ipmitool -f value -c UUID); do
openstack baremetal node set $uuid --driver ipmi --deploy-interface iscsi
baremetal node set $uuid --driver ipmi --deploy-interface iscsi
done
for uuid in $(baremetal node list --driver agent_ipmitool -f value -c UUID); do
@ -264,7 +264,7 @@ passthru methods from different vendor passthru implementations:
.. code-block:: shell
# set the vendor interface to 'vendor_foo`
openstack --os-baremetal-api-version 1.31 baremetal node set <node> --vendor-interface vendor_foo
baremetal node set <node> --vendor-interface vendor_foo
# invoke the vendor passthru method
openstack baremetal node passthru call <node> vendor_method_foo
baremetal node passthru call <node> vendor_method_foo

2
doc/source/contributor/contributing.rst
View File

@ -371,7 +371,7 @@ When filing bugs, please include as much detail as possible, and don't be shy.
Essential pieces of information are generally:
* Contents of the 'node' - `openstack baremetal node show <uuid>`
* Contents of the 'node' - `baremetal node show <uuid>`
* Steps to reproduce the issue.
* Exceptions and surrounding lines from the logs.
* Versions of ironic, ironic-python-agent, and any other coupled components.

6
doc/source/install/configure-nova-flavors.rst
View File

@ -66,8 +66,7 @@ with tagging some nodes with it:
.. code-block:: console
$ openstack --os-baremetal-api-version 1.21 baremetal node set $NODE_UUID \
--resource-class baremetal.with-GPU
$ baremetal node set $NODE_UUID --resource-class baremetal.with-GPU
.. warning::
It is possible to **add** a resource class to ``active`` nodes, but it is
@ -119,8 +118,7 @@ To add the standard trait ``HW_CPU_X86_VMX`` and a custom trait
.. code-block:: console
$ openstack --os-baremetal-api-version 1.37 baremetal node add trait \
$NODE_UUID CUSTOM_TRAIT1 HW_CPU_X86_VMX
$ baremetal node add trait $NODE_UUID CUSTOM_TRAIT1 HW_CPU_X86_VMX
Then, update the flavor to require these traits:

24
doc/source/install/enrollment.rst
View File

@ -54,7 +54,7 @@ command:
.. code-block:: console
$ openstack baremetal driver property list ipmi
$ baremetal driver property list ipmi
+----------------------+-------------------------------------------------------------------------------------------------------------+
| Property | Description |
+----------------------+-------------------------------------------------------------------------------------------------------------+
@ -170,15 +170,13 @@ and may be combined if desired.
.. code-block:: console
$ baremetal --os-baremetal-api-version 1.31 node set $NODE_UUID \
--deploy-interface direct \
--raid-interface agent
$ baremetal node set $NODE_UUID --deploy-interface direct --raid-interface agent
or set during node creation:
.. code-block:: console
$ baremetal --os-baremetal-api-version 1.31 node create --driver ipmi \
$ baremetal node create --driver ipmi \
--deploy-interface direct \
--raid-interface agent
@ -248,11 +246,11 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal port create $MAC_ADDRESS --node $NODE_UUID
$ baremetal port create $MAC_ADDRESS --node $NODE_UUID
.. note::
When it is time to remove the node from the Bare Metal service, the
command used to remove the port is ``openstack baremetal port delete
command used to remove the port is ``baremetal port delete
<port uuid>``. When doing so, it is important to ensure that the
baremetal node is not in ``maintenance`` as guarding logic to prevent
orphaning Neutron Virtual Interfaces (VIFs) will be overriden.
@ -279,15 +277,13 @@ Adding scheduling information
.. code-block:: console
$ openstack --os-baremetal-api-version 1.21 baremetal node set $NODE_UUID \
--resource-class $CLASS_NAME
$ baremetal node set $NODE_UUID --resource-class $CLASS_NAME
The ``--resource-class`` argument can also be used when creating a node:
.. code-block:: console
$ openstack --os-baremetal-api-version 1.21 baremetal node create \
--driver $DRIVER --resource-class $CLASS_NAME
$ baremetal node create --driver $DRIVER --resource-class $CLASS_NAME
To use resource classes for scheduling you need to update your flavors as
described in :doc:`configure-nova-flavors`.
@ -444,7 +440,7 @@ To move a node from ``enroll`` to ``manageable`` provision state:
.. code-block:: console
$ baremetal --os-baremetal-api-version 1.11 node manage $NODE_UUID
$ baremetal node manage $NODE_UUID
$ baremetal node show $NODE_UUID
+------------------------+--------------------------------------------------------------------+
| Property | Value |
@ -470,7 +466,7 @@ To move a node from ``manageable`` to ``available`` provision state:
.. code-block:: console
$ baremetal --os-baremetal-api-version 1.11 node provide $NODE_UUID
$ baremetal node provide $NODE_UUID
$ baremetal node show $NODE_UUID
+------------------------+--------------------------------------------------------------------+
| Property | Value |
@ -570,7 +566,7 @@ interfaces for a hardware type (for your deployment):
.. code-block:: console
$ baremetal --os-baremetal-api-version 1.31 driver show ipmi
$ baremetal driver show ipmi
+-------------------------------+----------------+
| Field | Value |
+-------------------------------+----------------+