openstack/ironic
Code Issues Proposed changes

Updates ironic documentation

Browse Source 
Updates ironic documentation to change "openstack baremetal" to "baremetal"

Change-Id: I95afa010aeb4fb08aff05adf0cfb7a200db8a53f
Story: #2008194
Task: #40962
This commit is contained in:
Kafilat Adeleke 2020-10-07 09:41:05 -07:00
parent 4c9cd83461
commit acdf1dc772
42 changed files with 256 additions and 256 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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
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 ``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
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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 |
+------------+-----------------------------------------+
@ -646,7 +646,7 @@ VIF attachments are stored on the port object, so deleting the port
Under normal circumstances, when deleting ports, a node should be in a
stable state, and the node should not be provisioned. If the
``openstack baremetal port delete`` command fails, this may indicate that
``baremetal port delete`` command fails, this may indicate that
a known VIF is still attached. Generally if they are transitory from cleaning,
provisioning, rescuing, or even inspection, getting the node to the
``available`` state wil unblock your delete operation, that is unless there is

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

@ -92,12 +92,12 @@ set new values for some or all interfaces:
export OS_BAREMETAL_API_VERSION=1.31
for uuid in $(openstack baremetal node list --driver pxe_ipmitool -f value -c UUID); do
for uuid in $(baremetal node list --driver pxe_ipmitool -f value -c UUID); do
openstack baremetal node set $uuid --driver ipmi --deploy-interface iscsi
done
for uuid in $(openstack baremetal node list --driver agent_ipmitool -f value -c UUID); do
openstack baremetal node set $uuid --driver ipmi --deploy-interface direct
for uuid in $(baremetal node list --driver agent_ipmitool -f value -c UUID); do
baremetal node set $uuid --driver ipmi --deploy-interface direct
done
See :doc:`/install/enrollment` for more details on setting hardware types and
@ -109,10 +109,10 @@ interfaces.
.. code-block:: console
openstack baremetal node maintenance set $UUID \
baremetal node maintenance set $UUID \
--reason "Changing driver and/or hardware interfaces"
# do the update, validate its correctness
openstack baremetal node maintenance unset $UUID
baremetal node maintenance unset $UUID
Other interfaces
----------------
@ -146,8 +146,8 @@ Then you can tell your nodes to use this interface, for example:
.. code-block:: console
export OS_BAREMETAL_API_VERSION=1.31
for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do
openstack baremetal node set $uuid --inspect-interface inspector
for uuid in $(baremetal node list --driver ipmi -f value -c UUID); do
baremetal node set $uuid --inspect-interface inspector
done
.. note::
@ -185,8 +185,8 @@ to update all nodes use:
.. code-block:: console
export OS_BAREMETAL_API_VERSION=1.31
for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do
openstack baremetal node set $uuid --console-interface ipmitool-shellinabox
for uuid in $(baremetal node list --driver ipmi -f value -c UUID); do
baremetal node set $uuid --console-interface ipmitool-shellinabox
done
RAID
@ -209,8 +209,8 @@ RAID interface. For example, to update all nodes use:
.. code-block:: console
export OS_BAREMETAL_API_VERSION=1.31
for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do
openstack baremetal node set $uuid --raid-interface agent
for uuid in $(baremetal node list --driver ipmi -f value -c UUID); do
baremetal node set $uuid --raid-interface agent
done
.. note::

2
doc/source/contributor/deploy-steps.rst
View File

@ -24,7 +24,7 @@ deploy step in the ``AgentDeploy`` class.
After deployment of the baremetal node, check the updated deploy steps::
openstack baremetal node show $node_ident -f json -c driver_internal_info
baremetal node show $node_ident -f json -c driver_internal_info
The above command outputs the ``driver_internal_info`` as following::

22
doc/source/contributor/dev-quickstart.rst
View File

@ -193,7 +193,7 @@ Step 1: Create a Python virtualenv
pip install python-openstackclient
#. Install the `openstack baremetal` client::
#. Install the `baremetal` client::
pip install python-ironicclient
@ -324,10 +324,10 @@ Then list the available commands and resources::
openstack help baremetal
# get the list of drivers currently supported by the available conductor(s)
openstack baremetal driver list
baremetal driver list
# get a list of nodes (should be empty at this point)
openstack baremetal node list
baremetal node list
Here is an example walkthrough of creating a node::
@ -339,7 +339,7 @@ Here is an example walkthrough of creating a node::
# enroll the node with the fake hardware type and IPMI-based power and
# management interfaces. Note that driver info may be added at node
# creation time with "--driver-info"
NODE=$(openstack baremetal node create \
NODE=$(baremetal node create \
--driver fake-hardware \
--management-interface ipmitool \
--power-interface ipmitool \
@ -348,20 +348,20 @@ Here is an example walkthrough of creating a node::
-f value -c uuid)
# driver info may also be added or updated later on
openstack baremetal node set $NODE --driver-info ipmi_password=$IPMI_PASS
baremetal node set $NODE --driver-info ipmi_password=$IPMI_PASS
# add a network port
openstack baremetal port create $MAC --node $NODE
baremetal port create $MAC --node $NODE
# view the information for the node
openstack baremetal node show $NODE
baremetal node show $NODE
# request that the node's driver validate the supplied information
openstack baremetal node validate $NODE
baremetal node validate $NODE
# you have now enrolled a node sufficiently to be able to control
# its power state from ironic!
openstack baremetal node power on $NODE
baremetal node power on $NODE
If you make some code changes and want to test their effects, simply stop the
services with Ctrl-C and restart them.
@ -710,7 +710,7 @@ Nova will be interfacing with Ironic conductor to spawn the node. On the
Ironic side, you should see an Ironic node associated with this Nova instance.
It should be powered on and in a 'wait call-back' provisioning state::
openstack baremetal node list
baremetal node list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
@ -735,7 +735,7 @@ This provisioning process may take some time depending on the performance of
the host system, but Ironic should eventually show the node as having an
'active' provisioning state::
openstack baremetal node list
baremetal node list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+

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

@ -27,7 +27,7 @@ enumerating this entrypoint by running the following python script::
A list of drivers enabled in a running Ironic service may be found by issuing
the following command against that API end point::
openstack baremetal driver list
baremetal driver list
Writing a hardware type
-----------------------

8
doc/source/install/configdrive.rst
View File

@ -47,13 +47,13 @@ and provide the file or HTTP URL to the Bare Metal service.
For the format of the configuration drive, Bare Metal service expects a
``gzipped`` and ``base64`` encoded ISO 9660 [#]_ file with a ``config-2``
label. The
:python-ironicclient-doc:`openstack baremetal client <cli/osc_plugin_cli.html>`
:python-ironicclient-doc:`baremetal client <cli/osc_plugin_cli.html>`
can generate a configuration drive in the `expected format`_. Just pass a
directory path containing the files that will be injected into it via the
``--config-drive`` parameter of the ``openstack baremetal node deploy``
``--config-drive`` parameter of the ``baremetal node deploy``
command, for example::
openstack baremetal node deploy $node_identifier --config-drive /dir/configdrive_files
baremetal node deploy $node_identifier --config-drive /dir/configdrive_files
Starting with the Stein release and `ironicclient` 2.7.0, you can request
building a configdrive on the server side by providing a JSON with keys
@ -61,7 +61,7 @@ building a configdrive on the server side by providing a JSON with keys
.. code-block:: bash
openstack baremetal node deploy $node_identifier \
baremetal node deploy $node_identifier \
--config-drive '{"meta_data": {"hostname": "server1.cluster"}}'
Configuration drive storage in an object store

2
doc/source/install/configure-ipv6-networking.rst
View File

@ -92,7 +92,7 @@ management, the ``local_link_connection`` field of baremetal ports must be set
to ``{'network_type': 'unmanaged'}``. The following example shows how to set the
local_link_connection for operation on unmanaged networks::
openstack baremetal port set \
baremetal port set \
--local-link-connection network_type=unmanaged <port-uuid>
The use of multiple IPv6 addresses must also be enabled in the Networking

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

@ -35,7 +35,7 @@ to list all drivers enabled on all hosts:
.. code-block:: console
openstack baremetal driver list
baremetal driver list
+---------------------+-----------------------+
| Supported driver(s) | Active host(s) |
+---------------------+-----------------------+
@ -119,7 +119,7 @@ and may be combined if desired.
.. code-block:: console
$ export OS_BAREMETAL_API_VERSION=1.11
$ openstack baremetal node create --driver ipmi
$ baremetal node create --driver ipmi
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+
@ -132,7 +132,7 @@ and may be combined if desired.
| name | None |
+--------------+--------------------------------------+
$ openstack baremetal node show dfc6189f-ad83-4261-9bda-b27258eb1987
$ baremetal node show dfc6189f-ad83-4261-9bda-b27258eb1987
+------------------------+--------------------------------------+
| Property | Value |
+------------------------+--------------------------------------+
@ -170,7 +170,7 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal --os-baremetal-api-version 1.31 node set $NODE_UUID \
$ baremetal --os-baremetal-api-version 1.31 node set $NODE_UUID \
--deploy-interface direct \
--raid-interface agent
@ -178,7 +178,7 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal --os-baremetal-api-version 1.31 node create --driver ipmi \
$ baremetal --os-baremetal-api-version 1.31 node create --driver ipmi \
--deploy-interface direct \
--raid-interface agent
@ -190,7 +190,7 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal node set $NODE_UUID \
$ baremetal node set $NODE_UUID \
--driver-info ipmi_username=$USER \
--driver-info ipmi_password=$PASS \
--driver-info ipmi_address=$ADDRESS
@ -202,14 +202,14 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal node set $NODE_UUID --driver-info ipmi_port=$PORT_NUMBER
$ baremetal node set $NODE_UUID --driver-info ipmi_port=$PORT_NUMBER
You may also specify all ``driver_info`` parameters during node
creation by passing the **--driver-info** option multiple times:
.. code-block:: console
$ openstack baremetal node create --driver ipmi \
$ baremetal node create --driver ipmi \
--driver-info ipmi_username=$USER \
--driver-info ipmi_password=$PASS \
--driver-info ipmi_address=$ADDRESS
@ -221,7 +221,7 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal node set $NODE_UUID \
$ baremetal node set $NODE_UUID \
--driver-info deploy_kernel=$DEPLOY_VMLINUZ_UUID \
--driver-info deploy_ramdisk=$DEPLOY_INITRD_UUID
@ -235,7 +235,7 @@ and may be combined if desired.
.. code-block:: console
$ openstack baremetal node set $NODE_UUID \
$ baremetal node set $NODE_UUID \
--driver-info cleaning_network=$CLEAN_UUID_OR_NAME \
--driver-info provisioning_network=$PROVISION_UUID_OR_NAME
@ -300,7 +300,7 @@ Adding scheduling information
.. code-block:: console
$ openstack baremetal node set $NODE_UUID \
$ baremetal node set $NODE_UUID \
--property cpus=$CPU_COUNT \
--property memory_mb=$RAM_MB \
--property local_gb=$DISK_GB
@ -310,7 +310,7 @@ Adding scheduling information
.. code-block:: console
$ openstack baremetal node create --driver ipmi \
$ baremetal node create --driver ipmi \
--driver-info ipmi_username=$USER \
--driver-info ipmi_password=$PASS \
--driver-info ipmi_address=$ADDRESS \
@ -339,7 +339,7 @@ Adding scheduling information
.. code-block:: console
$ openstack baremetal node set $NODE_UUID \
$ baremetal node set $NODE_UUID \
--property capabilities=key1:val1,key2:val2
Some capabilities can also be discovered during `Hardware Inspection`_.
@ -353,7 +353,7 @@ Adding scheduling information
.. code-block:: console
$ openstack baremetal node add trait $NODE_UUID \
$ baremetal node add trait $NODE_UUID \
CUSTOM_TRAIT1 HW_CPU_X86_VMX
@ -365,7 +365,7 @@ Validating node information
.. code-block:: console
$ openstack baremetal node validate $NODE_UUID
$ baremetal node validate $NODE_UUID
+------------+--------+--------+
| Interface | Result | Reason |
+------------+--------+--------+
@ -385,7 +385,7 @@ Validating node information
.. code-block:: console
$ openstack baremetal node validate $NODE_UUID
$ baremetal node validate $NODE_UUID
+------------+--------+-------------------------------------------------------------------------------------------------------------------------------------+
| Interface | Result | Reason |
+------------+--------+-------------------------------------------------------------------------------------------------------------------------------------+
@ -408,7 +408,7 @@ Validating node information
.. code-block:: console
$ openstack baremetal node validate $NODE_UUID
$ baremetal node validate $NODE_UUID
+------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Interface | Result | Reason |
+------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+
@ -444,8 +444,8 @@ To move a node from ``enroll`` to ``manageable`` provision state:
.. code-block:: console
$ openstack baremetal --os-baremetal-api-version 1.11 node manage $NODE_UUID
$ openstack baremetal node show $NODE_UUID
$ baremetal --os-baremetal-api-version 1.11 node manage $NODE_UUID
$ baremetal node show $NODE_UUID
+------------------------+--------------------------------------------------------------------+
| Property | Value |
+------------------------+--------------------------------------------------------------------+
@ -456,9 +456,9 @@ To move a node from ``enroll`` to ``manageable`` provision state:
+------------------------+--------------------------------------------------------------------+
.. note:: Since it is an asynchronous call, the response for
``openstack baremetal node manage`` will not indicate whether the
``baremetal node manage`` will not indicate whether the
transition succeeded or not. You can check the status of the
operation via ``openstack baremetal node show``. If it was successful,
operation via ``baremetal node show``. If it was successful,
``provision_state`` will be in the desired state. If it failed,
there will be information in the node's ``last_error``.
@ -470,8 +470,8 @@ To move a node from ``manageable`` to ``available`` provision state:
.. code-block:: console
$ openstack baremetal --os-baremetal-api-version 1.11 node provide $NODE_UUID
$ openstack baremetal node show $NODE_UUID
$ baremetal --os-baremetal-api-version 1.11 node provide $NODE_UUID
$ baremetal node show $NODE_UUID
+------------------------+--------------------------------------------------------------------+
| Property | Value |
+------------------------+--------------------------------------------------------------------+
@ -512,13 +512,13 @@ The node is named 'example' in the following examples:
.. code-block:: console
$ openstack baremetal node create --driver ipmi --name example
$ baremetal node create --driver ipmi --name example
or
.. code-block:: console
$ openstack baremetal node set $NODE_UUID --name example
$ baremetal node set $NODE_UUID --name example
Once assigned a logical name, a node can then be referred to by name or
@ -526,7 +526,7 @@ UUID interchangeably:
.. code-block:: console
$ openstack baremetal node create --driver ipmi --name example
$ baremetal node create --driver ipmi --name example
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+
@ -539,7 +539,7 @@ UUID interchangeably:
| name | example |
+--------------+--------------------------------------+
$ openstack baremetal node show example
$ baremetal node show example
+------------------------+--------------------------------------+
| Property | Value |
+------------------------+--------------------------------------+
@ -570,7 +570,7 @@ interfaces for a hardware type (for your deployment):
.. code-block:: console
$ openstack baremetal --os-baremetal-api-version 1.31 driver show ipmi
$ baremetal --os-baremetal-api-version 1.31 driver show ipmi
+-------------------------------+----------------+
| Field | Value |
+-------------------------------+----------------+
@ -641,7 +641,7 @@ A new node is created with the ``ipmi`` driver and no interfaces specified:
.. code-block:: console
$ export OS_BAREMETAL_API_VERSION=1.31
$ openstack baremetal node create --driver ipmi
$ baremetal node create --driver ipmi
+--------------+--------------------------------------+
| Property | Value |
+--------------+--------------------------------------+

4
doc/source/install/include/disk-label.inc
View File

@ -47,7 +47,7 @@ When Ironic is used with the Compute service the disk label should be
set to node's ``properties/capabilities`` field and also to the flavor
which will request such capability, for example::
openstack baremetal node set <node-uuid> --property capabilities='disk_label:gpt'
baremetal node set <node-uuid> --property capabilities='disk_label:gpt'
As for the flavor::
@ -59,4 +59,4 @@ When used in standalone mode
When used without the Compute service, the disk label should be set
directly to the node's ``instance_info`` field, as below::
openstack baremetal node set <node-uuid> --instance-info capabilities='{"disk_label": "gpt"}'
baremetal node set <node-uuid> --instance-info capabilities='{"disk_label": "gpt"}'

4
doc/source/install/include/local-boot-partition-images.inc
View File

@ -27,7 +27,7 @@ Enabling local boot with Compute service
To enable local boot we need to set a capability on the bare metal node,
for example::
openstack baremetal node set <node-uuid> --property capabilities="boot_option:local"
baremetal node set <node-uuid> --property capabilities="boot_option:local"
Nodes having ``boot_option`` set to ``local`` may be requested by adding
@ -53,4 +53,4 @@ we need a way to enable local boot when Compute is not present. To do that
we can simply specify the capability via the ``instance_info`` attribute
of the node, for example::
openstack baremetal node set <node-uuid> --instance-info capabilities='{"boot_option": "local"}'
baremetal node set <node-uuid> --instance-info capabilities='{"boot_option": "local"}'

6
doc/source/install/include/root-device-hints.inc
View File

@ -41,7 +41,7 @@ which disk it should pick for the deployment. The list of supported hints is:
To associate one or more hints with a node, update the node's properties
with a ``root_device`` key, for example::
openstack baremetal node set <node-uuid> --property root_device='{"wwn": "0x4000cca77fc4dba1"}'
baremetal node set <node-uuid> --property root_device='{"wwn": "0x4000cca77fc4dba1"}'
That will guarantee that Bare Metal service will pick the disk device that
@ -86,11 +86,11 @@ Examples are:
* Finding a disk larger or equal to 60 GiB and non-rotational (SSD)::
openstack baremetal node set <node-uuid> --property root_device='{"size": ">= 60", "rotational": false}'
baremetal node set <node-uuid> --property root_device='{"size": ">= 60", "rotational": false}'
* Finding a disk whose vendor is ``samsung`` or ``winsys``::
openstack baremetal node set <node-uuid> --property root_device='{"vendor": "<or> samsung <or> winsys"}'
baremetal node set <node-uuid> --property root_device='{"vendor": "<or> samsung <or> winsys"}'
.. note::
If multiple hints are specified, a device must satisfy all the hints.

4
doc/source/install/include/trusted-boot.inc
View File

@ -27,9 +27,9 @@ with PXE and Nova:
#. Enroll the node and update the node capability value::
openstack baremetal node create --driver ipmi
baremetal node create --driver ipmi
openstack baremetal node set $NODE_UUID --property capabilities={'trusted_boot':true}
baremetal node set $NODE_UUID --property capabilities={'trusted_boot':true}
#. Create a special flavor::

34
doc/source/install/standalone.rst
View File

@ -131,7 +131,7 @@ Using CLI
---------
To use the
:python-ironicclient-doc:`openstack baremetal CLI <cli/osc_plugin_cli.html>`,
:python-ironicclient-doc:`baremetal CLI <cli/osc_plugin_cli.html>`,
set up these environment variables. If the ``noauth`` authentication strategy is
being used, the value ``none`` must be set for OS_AUTH_TYPE. OS_ENDPOINT is
the URL of the ironic-api process.
@ -155,7 +155,7 @@ Enrolling nodes
name (for example, ``ipmi``). You can also specify all the required
driver parameters in one command. This will return the node UUID::
openstack baremetal node create --driver ipmi \
baremetal node create --driver ipmi \
--driver-info ipmi_address=ipmi.server.net \
--driver-info ipmi_username=user \
--driver-info ipmi_password=pass \
@ -189,7 +189,7 @@ Enrolling nodes
cards which are part of the node by creating a port with each NIC's MAC
address. In this case, they're used for naming of PXE configs for a node::
openstack baremetal port create $MAC_ADDRESS --node $NODE_UUID
baremetal port create $MAC_ADDRESS --node $NODE_UUID
Populating instance_info
------------------------
@ -233,7 +233,7 @@ Populating instance_info
For example::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info image_source=$IMG \
--instance-info image_checksum=$MD5HASH \
--instance-info kernel=$KERNEL \
@ -242,7 +242,7 @@ Populating instance_info
With a SHA256 hash::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info image_source=$IMG \
--instance-info image_os_hash_algo=sha256 \
--instance-info image_os_hash_value=$SHA256HASH \
@ -252,7 +252,7 @@ Populating instance_info
With a whole disk image::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info image_source=$IMG \
--instance-info image_checksum=$MD5HASH
@ -260,12 +260,12 @@ Populating instance_info
format, you may want them cached locally, converted to raw and served from
the conductor's HTTP server::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info image_download_source=local
#. :ref:`Boot mode <boot_mode_support>` can be specified per instance::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info deploy_boot_mode=uefi
Otherwise, the ``boot_mode`` capability from the node's ``properties`` will
@ -282,13 +282,13 @@ Populating instance_info
#. To override the :ref:`boot option <local-boot-partition-images>` used for
this instance, set the ``boot_option`` capability::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info capabilities='{"boot_option": "local"}'
#. Starting with the Ussuri release, you can set :ref:`root device hints
<root-device-hints>` per instance::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info root_device='{"wwn": "0x4000cca77fc4dba1"}'
This setting overrides any previous setting in ``properties`` and will be
@ -305,7 +305,7 @@ Deployment
#. Validate that all parameters are correct::
openstack baremetal node validate $NODE_UUID
baremetal node validate $NODE_UUID
+------------+--------+----------------------------------------------------------------+
| Interface | Result | Reason |
@ -323,7 +323,7 @@ Deployment
#. Now you can start the deployment, run::
openstack baremetal node deploy $NODE_UUID
baremetal node deploy $NODE_UUID
Ramdisk booting
@ -341,18 +341,18 @@ To use, a few different settings must be modified.
#. Change the ``deploy_interface`` on the node to ``ramdisk``::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--deploy-interface ramdisk
#. Set a kernel and ramdisk to be utilized::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info kernel=$KERNEL_URL \
--instance-info ramdisk=$RAMDISK_URL
#. Deploy the node::
openstack baremetal node deploy $NODE_UUID
baremetal node deploy $NODE_UUID
.. warning::
Configuration drives, also known as a configdrive, is not supported
@ -376,12 +376,12 @@ be booted.
#. Store the URL to the ISO image to ``instance_info/boot_iso``,
instead of a ``kernel`` or ``ramdisk`` setting::
openstack baremetal node set $NODE_UUID \
baremetal node set $NODE_UUID \
--instance-info boot_iso=$BOOT_ISO_URL
#. Deploy the node::
openstack baremetal node deploy $NODE_UUID
baremetal node deploy $NODE_UUID
.. warning::

12
doc/source/install/troubleshooting.rst
View File

@ -21,14 +21,14 @@ therein should match the bare metal node properties, and the Compute service fla
Here is an example set of commands to compare the resources in Compute
service and Bare Metal service::
$ openstack baremetal node list
$ baremetal node list
+--------------------------------------+---------------+-------------+--------------------+-------------+
| UUID | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+---------------+-------------+--------------------+-------------+
| 86a2b1bb-8b29-4964-a817-f90031debddb | None | power off | available | False |
+--------------------------------------+---------------+-------------+--------------------+-------------+
$ openstack baremetal node show 86a2b1bb-8b29-4964-a817-f90031debddb
$ baremetal node show 86a2b1bb-8b29-4964-a817-f90031debddb
+------------------------+----------------------------------------------------------------------+
| Property | Value |
+------------------------+----------------------------------------------------------------------+
@ -99,7 +99,7 @@ the node to the nova scheduler. Nodes can be placed into maintenance mode
with the following command.
::
$ openstack baremetal node maintenance set $NODE_UUID
$ baremetal node maintenance set $NODE_UUID
A maintenance reason may be included with the optional ``--reason`` command
line option. This is a free form text field that will be displayed in the
@ -107,9 +107,9 @@ line option. This is a free form text field that will be displayed in the
::
$ openstack baremetal node maintenance set $UUID --reason "Need to add ram."
$ baremetal node maintenance set $UUID --reason "Need to add ram."
$ openstack baremetal node show $UUID
$ baremetal node show $UUID
+------------------------+--------------------------------------+
| Property | Value |
@ -128,4 +128,4 @@ To remove maintenance mode and clear any ``maintenance_reason`` use the
following command.
::
$ openstack baremetal node maintenance unset $NODE_UUID
$ baremetal node maintenance unset $NODE_UUID