Merge "Update .rst files"

17 files changed, 59 insertions, 70 deletions

diff --git a/doc/source/admin/adoption.rst b/doc/source/admin/adoption.rst
index 3f5c212d4..3bb023881 100644
--- a/doc/source/admin/adoption.rst
+++ b/doc/source/admin/adoption.rst
@@ -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
diff --git a/doc/source/admin/bios.rst b/doc/source/admin/bios.rst
index 20f9acec3..0aa691c2f 100644
--- a/doc/source/admin/bios.rst
+++ b/doc/source/admin/bios.rst
@@ -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::
diff --git a/doc/source/admin/boot-from-volume.rst b/doc/source/admin/boot-from-volume.rst
index 9dbe1aa7a..7e80d5a11 100644
--- a/doc/source/admin/boot-from-volume.rst
+++ b/doc/source/admin/boot-from-volume.rst
@@ -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
diff --git a/doc/source/admin/console.rst b/doc/source/admin/console.rst
index 8aef2a3df..82f63ca98 100644
--- a/doc/source/admin/console.rst
+++ b/doc/source/admin/console.rst
@@ -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                                                                |
  +-----------------+----------------------------------------------------------------------+
diff --git a/doc/source/admin/drivers.rst b/doc/source/admin/drivers.rst
index 1e7c5330e..7df4dc6ad 100644
--- a/doc/source/admin/drivers.rst
+++ b/doc/source/admin/drivers.rst
@@ -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::
 
diff --git a/doc/source/admin/drivers/idrac.rst b/doc/source/admin/drivers/idrac.rst
index 223e09461..aa6503215 100644
--- a/doc/source/admin/drivers/idrac.rst
+++ b/doc/source/admin/drivers/idrac.rst
@@ -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}
 
 
diff --git a/doc/source/admin/drivers/ilo.rst b/doc/source/admin/drivers/ilo.rst
index 135cf6887..6974fdb49 100644
--- a/doc/source/admin/drivers/ilo.rst
+++ b/doc/source/admin/drivers/ilo.rst
@@ -235,7 +235,7 @@ The following command can be used to enroll a ProLiant node with
 
 .. code-block:: console
 
-    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 \
diff --git a/doc/source/admin/drivers/irmc.rst b/doc/source/admin/drivers/irmc.rst
index a90761cdb..20ac68c42 100644
--- a/doc/source/admin/drivers/irmc.rst
+++ b/doc/source/admin/drivers/irmc.rst
@@ -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:
 
diff --git a/doc/source/admin/drivers/snmp.rst b/doc/source/admin/drivers/snmp.rst
index 50787d0ad..7a91bc126 100644
--- a/doc/source/admin/drivers/snmp.rst
+++ b/doc/source/admin/drivers/snmp.rst
@@ -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> \
diff --git a/doc/source/admin/node-deployment.rst b/doc/source/admin/node-deployment.rst
index bc53c7065..4a1a3310c 100644
--- a/doc/source/admin/node-deployment.rst
+++ b/doc/source/admin/node-deployment.rst
@@ -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
diff --git a/doc/source/admin/portgroups.rst b/doc/source/admin/portgroups.rst
index dd7bc707a..d66917179 100644
--- a/doc/source/admin/portgroups.rst
+++ b/doc/source/admin/portgroups.rst
@@ -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
diff --git a/doc/source/admin/raid.rst b/doc/source/admin/raid.rst
index 22e42c782..06a7c3f27 100644
--- a/doc/source/admin/raid.rst
+++ b/doc/source/admin/raid.rst
@@ -27,7 +27,7 @@ Ironic Python Agent ramdisk. For in-band hardware RAID configuration,
 a hardware manager which supports RAID should be bundled with the ramdisk.
 
 Whether a node supports RAID configuration could be found using the CLI
-command ``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
diff --git a/doc/source/admin/troubleshooting.rst b/doc/source/admin/troubleshooting.rst
index 505e4d871..e774bbc3e 100644
--- a/doc/source/admin/troubleshooting.rst
+++ b/doc/source/admin/troubleshooting.rst
@@ -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.
diff --git a/doc/source/admin/upgrade-to-hardware-types.rst b/doc/source/admin/upgrade-to-hardware-types.rst
index 934dc412c..1a4757524 100644
--- a/doc/source/admin/upgrade-to-hardware-types.rst
+++ b/doc/source/admin/upgrade-to-hardware-types.rst
@@ -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
diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst
index 7295da979..572f97850 100644
--- a/doc/source/contributor/contributing.rst
+++ b/doc/source/contributor/contributing.rst
@@ -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.
diff --git a/doc/source/install/configure-nova-flavors.rst b/doc/source/install/configure-nova-flavors.rst
index 0ec483d66..76cfbf3e9 100644
--- a/doc/source/install/configure-nova-flavors.rst
+++ b/doc/source/install/configure-nova-flavors.rst
@@ -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:
 
diff --git a/doc/source/install/enrollment.rst b/doc/source/install/enrollment.rst
index a60ab9408..ce20f5aad 100644
--- a/doc/source/install/enrollment.rst
+++ b/doc/source/install/enrollment.rst
@@ -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          |
     +-------------------------------+----------------+