diff --git a/doc/source/admin/adoption.rst b/doc/source/admin/adoption.rst index daa7803c27..3f5c212d42 100644 --- a/doc/source/admin/adoption.rst +++ b/doc/source/admin/adoption.rst @@ -121,7 +121,7 @@ from the ``manageable`` state to ``active`` state:: # 1.17, which introduces the adoption capability. export OS_BAREMETAL_API_VERSION=1.17 - openstack baremetal node create --name testnode \ + baremetal node create --name testnode \ --driver ipmi \ --driver-info ipmi_address= \ --driver-info ipmi_username= \ @@ -129,15 +129,15 @@ from the ``manageable`` state to ``active`` state:: --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= - openstack baremetal port create --node + baremetal port create --node - 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 --instance-uuid + baremetal node set --instance-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 + baremetal node manage 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 + baremetal node delete diff --git a/doc/source/admin/bios.rst b/doc/source/admin/bios.rst index 183e248426..20f9acec3d 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:: - $ openstack baremetal node bios setting list + $ baremetal node bios setting list 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 + $ baremetal node bios setting show 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 fd89360a6d..9dbe1aa7ae 100644 --- a/doc/source/admin/boot-from-volume.rst +++ b/doc/source/admin/boot-from-volume.rst @@ -146,11 +146,11 @@ contains more extensive validation, that is likely un-necessary in a Setting the external storage interface:: - openstack baremetal node set --storage-interface external $NODE_UUID + baremetal node set --storage-interface external $NODE_UUID Setting a volume:: - openstack baremetal volume target create --node $NODE_UUID \ + baremetal volume target create --node $NODE_UUID \ --type iscsi --boot-index 0 --volume-id $VOLUME_UUID \ --property target_iqn="iqn.2010-10.com.example:vol-X" \ --property target_lun="0" \ @@ -161,12 +161,12 @@ Setting a volume:: Ensure that no image_source is defined:: - openstack baremetal node unset \ + baremetal node unset \ --instance-info image_source $NODE_UUID Deploy the node:: - openstack baremetal node deploy $NODE_UUID + baremetal node deploy $NODE_UUID Upon deploy, the boot interface for the baremetal node will attempt to either create iPXE configuration OR set boot parameters out-of-band via diff --git a/doc/source/admin/cleaning.rst b/doc/source/admin/cleaning.rst index 67c6c9e9fc..8338a8b175 100644 --- a/doc/source/admin/cleaning.rst +++ b/doc/source/admin/cleaning.rst @@ -154,10 +154,10 @@ In the above example, the node's RAID interface would configure hardware RAID without non-root volumes, and then all devices would be erased (in that order). -Starting manual cleaning via "openstack baremetal" CLI +Starting manual cleaning via "openstack metal" CLI ------------------------------------------------------ -Manual cleaning is available via the ``openstack baremetal node clean`` +Manual cleaning is available via the ``baremetal node clean`` command, starting with Bare Metal API version 1.15. The argument ``--clean-steps`` must be specified. Its value is one of: @@ -175,20 +175,20 @@ add ``--os-baremetal-api-version 1.15`` to the command.):: Examples of doing this with a JSON string:: - openstack baremetal node clean \ + baremetal node clean \ --clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]' - openstack baremetal node clean \ + baremetal node clean \ --clean-steps '[{"interface": "deploy", "step": "erase_devices"}]' Or with a file:: - openstack baremetal node clean \ + baremetal node clean \ --clean-steps my-clean-steps.txt Or with stdin:: - cat my-clean-steps.txt | openstack baremetal node clean \ + cat my-clean-steps.txt | baremetal node clean \ --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. diff --git a/doc/source/admin/conductor-groups.rst b/doc/source/admin/conductor-groups.rst index e6a50cfc6d..941d024c37 100644 --- a/doc/source/admin/conductor-groups.rst +++ b/doc/source/admin/conductor-groups.rst @@ -58,7 +58,7 @@ expression. #. Set the conductor group on one or more nodes:: - openstack baremetal node set \ + baremetal node set \ --conductor-group "OperatorDefinedString" #. As desired and as needed, remaining conductors can be updated with diff --git a/doc/source/admin/console.rst b/doc/source/admin/console.rst index 6189547995..8aef2a3df3 100644 --- a/doc/source/admin/console.rst +++ b/doc/source/admin/console.rst @@ -124,23 +124,23 @@ The web console can be configured in Bare Metal service in the following way: Enable the web console, for example:: - openstack baremetal node set \ + baremetal node set \ --driver-info = - openstack baremetal node console enable + baremetal node console enable Check whether the console is enabled, for example:: - openstack baremetal node validate + baremetal node validate Disable the web console, for example:: - openstack baremetal node console disable - openstack baremetal node unset --driver-info + baremetal node console disable + baremetal node unset --driver-info The ```` is driver dependent. The actual name of this field can be checked in driver properties, for example:: - openstack baremetal driver property list + baremetal driver property list For the ``ipmi`` hardware type, this option is ``ipmi_terminal_port``. Give a customized port number to ````, @@ -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 + baremetal node console show +-----------------+----------------------------------------------------------------------+ | 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 --driver-info ipmi_terminal_port= - openstack baremetal node console enable + baremetal node set --driver-info ipmi_terminal_port= + baremetal node console enable Check whether the serial console is enabled, for example:: - openstack baremetal node validate + baremetal node validate Disable the serial console, for example:: - openstack baremetal node console disable - openstack baremetal node unset --driver-info + baremetal node console disable + baremetal node unset --driver-info 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 + baremetal node console show +-----------------+----------------------------------------------------------------------+ | Property | Value | +-----------------+----------------------------------------------------------------------+ diff --git a/doc/source/admin/drivers.rst b/doc/source/admin/drivers.rst index 267409403e..1e7c5330e7 100644 --- a/doc/source/admin/drivers.rst +++ b/doc/source/admin/drivers.rst @@ -38,7 +38,7 @@ enrolling as described in :doc:`/install/enrollment`:: Any hardware interfaces can be specified on enrollment as well:: - openstack baremetal node create --driver \ + baremetal node create --driver \ --deploy-interface direct ---interface 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 \ + baremetal node set \ --deploy-interface direct \ ---interface @@ -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--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 --management-interface noop + baremetal node set --management-interface noop Unsupported drivers ------------------- diff --git a/doc/source/admin/drivers/ansible.rst b/doc/source/admin/drivers/ansible.rst index 3c1a7436c0..c455b4ef69 100644 --- a/doc/source/admin/drivers/ansible.rst +++ b/doc/source/admin/drivers/ansible.rst @@ -188,12 +188,12 @@ configuration file, for their descriptions and default values please see Driver properties for the Node ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Set them per-node via ``openstack baremetal node set`` command, +Set them per-node via ``baremetal node set`` command, for example: .. code-block:: shell - openstack baremetal node set \ + baremetal node set \ --deploy-interface ansible \ --driver-info ansible_username=stack \ --driver-info ansible_key_file=/etc/ironic/id_rsa diff --git a/doc/source/admin/drivers/ibmc.rst b/doc/source/admin/drivers/ibmc.rst index 86d89c057d..84786df02e 100644 --- a/doc/source/admin/drivers/ibmc.rst +++ b/doc/source/admin/drivers/ibmc.rst @@ -86,12 +86,12 @@ field: verification. To disable verifying TLS_, set this to False. This is optional. -The ``openstack baremetal node create`` command can be used to enroll +The ``baremetal node create`` command can be used to enroll a node with the ``ibmc`` driver. For example: .. code-block:: bash - openstack baremetal node create --driver ibmc + baremetal node create --driver ibmc --driver-info ibmc_address=https://example.com \ --driver-info ibmc_username=admin \ --driver-info ibmc_password=password diff --git a/doc/source/admin/drivers/idrac.rst b/doc/source/admin/drivers/idrac.rst index f77eb8dc4f..223e09461f 100644 --- a/doc/source/admin/drivers/idrac.rst +++ b/doc/source/admin/drivers/idrac.rst @@ -159,7 +159,7 @@ hardware type using WSMAN for all interfaces: .. code-block:: bash - openstack baremetal node create --driver idrac \ + baremetal node create --driver idrac \ --driver-info drac_username=user \ --driver-info drac_password=pa$$w0rd \ --driver-info drac_address=drac.host @@ -169,7 +169,7 @@ hardware type using Redfish for all interfaces: .. code-block:: bash - openstack baremetal node create --driver idrac \ + baremetal node create --driver idrac \ --driver-info redfish_username=user \ --driver-info redfish_password=pa$$w0rd \ --driver-info redfish_address=drac.host \ @@ -186,7 +186,7 @@ hardware type assuming a mix of Redfish and WSMAN interfaces are used: .. code-block:: bash - openstack baremetal node create --driver idrac \ + baremetal node create --driver idrac \ --driver-info drac_username=user \ --driver-info drac_password=pa$$w0rd --driver-info drac_address=drac.host \ @@ -360,7 +360,7 @@ hot spare physical disks, and clears foreign configuration: .. code-block:: bash - openstack baremetal node clean --clean-steps \ + baremetal node clean --clean-steps \ '[{"interface": "raid", "step": "delete_configuration"}]' ${node_uuid} @@ -369,7 +369,7 @@ configuration: .. code-block:: bash - openstack baremetal node set --target-raid-config '{ "logical_disks": + baremetal node set --target-raid-config '{ "logical_disks": [ { "controller": "RAID.Integrated.1-1", "is_root_volume": true, "physical_disks": [ @@ -459,7 +459,7 @@ Get BIOS Config .. code-block:: bash - openstack baremetal node passthru call --http-method GET ${node_uuid} get_bios_config + baremetal node passthru call --http-method GET ${node_uuid} get_bios_config Snippet of output showing virtualization enabled: @@ -491,7 +491,7 @@ Set BIOS Config .. code-block:: bash - openstack baremetal node passthru call ${node_uuid} set_bios_config --arg "name=value" + baremetal node passthru call ${node_uuid} set_bios_config --arg "name=value" Walkthrough of perfoming a BIOS configuration change: @@ -505,7 +505,7 @@ two properties that are being changed are: .. code-block:: bash - openstack baremetal node passthru call ${node_uuid} set_bios_config \ + baremetal node passthru call ${node_uuid} set_bios_config \ --arg "ProcVirtualization=Enabled" \ --arg "SriovGlobalEnable=Enabled" @@ -532,7 +532,7 @@ Ironic power API. .. code-block:: bash - openstack baremetal node passthru call ${node_uuid} commit_bios_config \ + baremetal node passthru call ${node_uuid} commit_bios_config \ --arg "reboot=true" .. code-block:: json @@ -546,7 +546,7 @@ The state of any executing job can be queried: .. code-block:: bash - openstack baremetal node passthru call --http-method GET ${node_uuid} list_unfinished_jobs + baremetal node passthru call --http-method GET ${node_uuid} list_unfinished_jobs .. code-block:: json @@ -568,7 +568,7 @@ Instead of committing, a pending change can be abandoned: .. code-block:: bash - openstack baremetal node passthru call --http-method DELETE ${node_uuid} abandon_bios_config + baremetal node passthru call --http-method DELETE ${node_uuid} abandon_bios_config The abandon command does not provide a response body. @@ -609,18 +609,18 @@ The boot mode can be changed via the vendor passthru interface as follows: .. code-block:: bash - openstack baremetal node passthru call ${node_uuid} set_bios_config \ + baremetal node passthru call ${node_uuid} set_bios_config \ --arg "BootMode=Uefi" - openstack baremetal node passthru call ${node_uuid} commit_bios_config \ + baremetal node passthru call ${node_uuid} commit_bios_config \ --arg "reboot=true" .. code-block:: bash - openstack baremetal node passthru call ${node_uuid} set_bios_config \ + baremetal node passthru call ${node_uuid} set_bios_config \ --arg "BootMode=Bios" - openstack baremetal node passthru call ${node_uuid} commit_bios_config \ + baremetal node passthru call ${node_uuid} commit_bios_config \ --arg "reboot=true" Known Issues @@ -661,7 +661,7 @@ time as waiting for iDRAC to become ready again and then time out, for example: .. code-block:: bash - openstack baremetal node passthru call --http-method GET \ + baremetal node passthru call --http-method GET \ aed58dca-1b25-409a-a32f-3a817d59e1e0 list_unfinished_jobs Timed out waiting for a reply to message ID 547ce7995342418c99ef1ea4a0054572 (HTTP 500) diff --git a/doc/source/admin/drivers/ilo.rst b/doc/source/admin/drivers/ilo.rst index 7e32a69703..135cf68873 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 - 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 --property capabilities='boot_mode:uefi' + baremetal node set --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 --property capabilities='secure_boot:true' + baremetal node set --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 + baremetal node inject nmi 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 ] - openstack baremetal node power off --soft \ + baremetal node power off --soft \ [--power-timeout ] .. 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 \ diff --git a/doc/source/admin/drivers/intel-ipmi.rst b/doc/source/admin/drivers/intel-ipmi.rst index 256ab15ce3..4872ba1f98 100644 --- a/doc/source/admin/drivers/intel-ipmi.rst +++ b/doc/source/admin/drivers/intel-ipmi.rst @@ -73,10 +73,10 @@ All the configuration value required for IntelIPMI is the same as the IPMI hardware type except the management interface which is ``intel-ipmitool``. Refer :doc:`ipmitool` for details. -The ``openstack baremetal node create`` command can be used to enroll a node +The ``baremetal node create`` command can be used to enroll a node with an IntelIPMI driver. For example:: - openstack baremetal node create --driver intel-ipmi \ + baremetal node create --driver intel-ipmi \ --driver-info ipmi_address=
\ --driver-info ipmi_username= \ --driver-info ipmi_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 diff --git a/doc/source/admin/drivers/ipa.rst b/doc/source/admin/drivers/ipa.rst index 9d3e1f31a4..3a5aa57c40 100644 --- a/doc/source/admin/drivers/ipa.rst +++ b/doc/source/admin/drivers/ipa.rst @@ -119,4 +119,4 @@ that, you have to update the node's ``driver_info`` field and set the ``deploy_forces_oob_reboot`` parameter with the value of **True**. For example, the below command sets this configuration in a specific node:: - openstack baremetal node set --driver-info deploy_forces_oob_reboot=True + baremetal node set --driver-info deploy_forces_oob_reboot=True diff --git a/doc/source/admin/drivers/ipmitool.rst b/doc/source/admin/drivers/ipmitool.rst index b9cca3e4ac..6daf84fc99 100644 --- a/doc/source/admin/drivers/ipmitool.rst +++ b/doc/source/admin/drivers/ipmitool.rst @@ -74,10 +74,10 @@ good practice to have them set: It is highly recommend that you setup a username and password for your BMC. -The ``openstack baremetal node create`` command can be used to enroll a node +The ``baremetal node create`` command can be used to enroll a node with an IPMItool-based driver. For example:: - openstack baremetal node create --driver ipmi \ + baremetal node create --driver ipmi \ --driver-info ipmi_address=
\ --driver-info ipmi_username= \ --driver-info ipmi_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 \ + baremetal node set \ --driver-info ipmi_local_address=
\ --driver-info ipmi_bridging=single \ --driver-info ipmi_target_channel= \ @@ -139,7 +139,7 @@ driver. For example: * Double Bridging:: - openstack baremetal node set \ + baremetal node set \ --driver-info ipmi_local_address=
\ --driver-info ipmi_bridging=dual \ --driver-info ipmi_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 --driver-info ipmi_protocol_version= + baremetal node set --driver-info ipmi_protocol_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 --driver-info ipmi_cipher_suite=3 + baremetal node set --driver-info ipmi_cipher_suite=3 Static boot order configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/admin/drivers/irmc.rst b/doc/source/admin/drivers/irmc.rst index 1fa1088e0a..a90761cdbe 100644 --- a/doc/source/admin/drivers/irmc.rst +++ b/doc/source/admin/drivers/irmc.rst @@ -203,7 +203,7 @@ following sections describe both methods: To enable secure boot we need to set a capability on the bare metal node and the bare metal flavor, for example:: - openstack baremetal node set --property capabilities='secure_boot:true' + baremetal node set --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 --instance-info capabilities='{"secure_boot": "true"}' + baremetal node set --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 \ + $ baremetal node set \ --target-raid-config Here is some sample values for JSON file:: diff --git a/doc/source/admin/drivers/redfish.rst b/doc/source/admin/drivers/redfish.rst index eb723b34a7..b389be52a9 100644 --- a/doc/source/admin/drivers/redfish.rst +++ b/doc/source/admin/drivers/redfish.rst @@ -90,12 +90,12 @@ field: as ``[redfish]auth_type``. -The ``openstack baremetal node create`` command can be used to enroll +The ``baremetal node create`` command can be used to enroll a node with the ``redfish`` driver. For example: .. code-block:: bash - openstack baremetal node create --driver redfish --driver-info \ + baremetal node create --driver redfish --driver-info \ redfish_address=https://example.com --driver-info \ redfish_system_id=/redfish/v1/Systems/CX34R87 --driver-info \ redfish_username=admin --driver-info redfish_password=password \ @@ -164,7 +164,7 @@ BIOS boot mode, it suffice to set ironic boot interface to .. code-block:: bash - openstack baremetal node set --boot-interface redfish-virtual-media node-0 + baremetal node set --boot-interface redfish-virtual-media node-0 If UEFI boot mode is desired, the user should additionally supply EFI System Partition image (ESP_) via ``[driver-info]/bootloader`` ironic node @@ -172,7 +172,7 @@ property or ironic configuration file in form of Glance image UUID or a URL. .. code-block:: bash - openstack baremetal node set --driver-info bootloader= node-0 + baremetal node set --driver-info bootloader= 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-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 --clean-steps firmware_update.json + baremetal node clean --clean-steps firmware_update.json In the following example, the JSON is specified directly on the command line:: - openstack baremetal node clean --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 --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 diff --git a/doc/source/admin/drivers/snmp.rst b/doc/source/admin/drivers/snmp.rst index 242c03457e..50787d0ad9 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 - openstack baremetal node set --property capabilities="boot_option:netboot" + baremetal node set --property capabilities="boot_option:netboot" 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= \ --driver-info snmp_address= \ --driver-info snmp_outlet= \ diff --git a/doc/source/admin/drivers/xclarity.rst b/doc/source/admin/drivers/xclarity.rst index 20a310c2c9..427007c3a0 100644 --- a/doc/source/admin/drivers/xclarity.rst +++ b/doc/source/admin/drivers/xclarity.rst @@ -55,12 +55,12 @@ field and are required: xclarity_username to the XClarity Controller. - ``xclarity_hardware_id``: The hardware ID of the XClarity managed server. -The ``openstack baremetal node create`` command can be used to enroll +The ``baremetal node create`` command can be used to enroll a node with the ``xclarity`` driver. For example: .. code-block:: bash - openstack baremetal node create --driver xclarity \ + baremetal node create --driver xclarity \ --driver-info xclarity_manager_ip=https://10.240.217.101 \ --driver-info xclarity_username=admin \ --driver-info xclarity_password=password \ diff --git a/doc/source/admin/inspection.rst b/doc/source/admin/inspection.rst index 41605f1b10..231498fba1 100644 --- a/doc/source/admin/inspection.rst +++ b/doc/source/admin/inspection.rst @@ -25,11 +25,11 @@ The node should be in the ``manageable`` state before inspection is initiated. If it is in the ``enroll`` or ``available`` state, move it to ``manageable`` first:: - openstack baremetal node manage + baremetal node manage Then inspection can be initiated using the following command:: - openstack baremetal node inspect + baremetal node inspect .. _capabilities-discovery: diff --git a/doc/source/admin/interfaces/boot.rst b/doc/source/admin/interfaces/boot.rst index bae9d24607..35d5561e36 100644 --- a/doc/source/admin/interfaces/boot.rst +++ b/doc/source/admin/interfaces/boot.rst @@ -49,7 +49,7 @@ costly than a non-persistent one, so this can bring performance improvements. Set the flag ``force_persistent_boot_device`` to ``True`` in the node's ``driver_info``:: - $ openstack baremetal node set --driver-info force_persistent_boot_device=True + $ baremetal node set --driver-info force_persistent_boot_device=True .. note:: It's recommended to check if the node's state has not changed as there diff --git a/doc/source/admin/interfaces/deploy.rst b/doc/source/admin/interfaces/deploy.rst index 39c8eecb14..9aef8a77b3 100644 --- a/doc/source/admin/interfaces/deploy.rst +++ b/doc/source/admin/interfaces/deploy.rst @@ -20,8 +20,8 @@ This interface is used by default, if enabled (see :ref:`enable-hardware-interfaces`). You can specify it explicitly when creating or updating a node:: - openstack baremetal node create --driver ipmi --deploy-interface iscsi - openstack baremetal node set --deploy-interface iscsi + baremetal node create --driver ipmi --deploy-interface iscsi + baremetal node set --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 --deploy-interface direct + baremetal node create --driver ipmi --deploy-interface direct + baremetal node set --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 --driver-info image_download_source=local + baremetal node set --driver-info image_download_source=local or per instance in ``instance_info``:: - openstack baremetal node set --instance-info image_download_source=local + baremetal node set --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 --deploy-interface ansible + baremetal node create --driver ipmi --deploy-interface ansible + baremetal node set --deploy-interface ansible For more information about this deploy interface, its features and how to use it, see :doc:`Ansible deploy interface <../drivers/ansible>`. diff --git a/doc/source/admin/multitenancy.rst b/doc/source/admin/multitenancy.rst index f3fa994bf5..652c46fa21 100644 --- a/doc/source/admin/multitenancy.rst +++ b/doc/source/admin/multitenancy.rst @@ -135,7 +135,7 @@ Configuring nodes ironic-conductor's configuration file. Set it to ``neutron`` to use the Networking service's ML2 driver:: - openstack baremetal node create --network-interface neutron --driver ipmi + baremetal node create --network-interface neutron --driver ipmi .. note:: If the ``[DEFAULT]/default_network_interface`` configuration option is @@ -145,12 +145,12 @@ Configuring nodes #. To update an existing node's network interface to ``neutron``, use the following commands:: - openstack baremetal node set $NODE_UUID_OR_NAME \ + baremetal node set $NODE_UUID_OR_NAME \ --network-interface neutron #. Create a port as follows:: - openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ + baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ --local-link-connection switch_id=$SWITCH_MAC_ADDRESS \ --local-link-connection switch_info=$SWITCH_HOSTNAME \ --local-link-connection port_id=$SWITCH_PORT \ @@ -169,14 +169,14 @@ Configuring nodes the port GUID's lower 3 and higher 3 bytes. In this example it would be f4:52:14:38:39:81. Putting it all together, create an Infiniband port as follows:: - openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ + baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ --pxe-enabled true \ --extra client-id=$CLIENT_ID \ --physical-network physnet1 #. Create a Smart NIC port as follows:: - openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ + baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ --local-link-connection hostname=$HOSTNAME \ --local-link-connection port_id=$REP_NAME \ --pxe-enabled true \ @@ -188,7 +188,7 @@ Configuring nodes #. Check the port configuration:: - openstack baremetal port show $PORT_UUID + baremetal port show $PORT_UUID After these steps, the provisioning of the created node will happen in the provisioning network, and then the node will be moved to the tenant network diff --git a/doc/source/admin/node-deployment.rst b/doc/source/admin/node-deployment.rst index b3f8bfe4f0..bc53c70653 100644 --- a/doc/source/admin/node-deployment.rst +++ b/doc/source/admin/node-deployment.rst @@ -219,10 +219,10 @@ single step: Further information on this API is available `here `__. -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: diff --git a/doc/source/admin/node-multitenancy.rst b/doc/source/admin/node-multitenancy.rst index e6214049df..4b46404f9c 100644 --- a/doc/source/admin/node-multitenancy.rst +++ b/doc/source/admin/node-multitenancy.rst @@ -16,8 +16,8 @@ Setting the Owner and Lessee Non-administrative access to a node is controlled through a node's ``owner`` or ``lessee`` attribute:: - openstack baremetal node set --owner 080925ee2f464a2c9dce91ee6ea354e2 node-7 - openstack baremetal node set --lessee 2a210e5ff114c8f2b6e994218f51a904 node-10 + baremetal node set --owner 080925ee2f464a2c9dce91ee6ea354e2 node-7 + baremetal node set --lessee 2a210e5ff114c8f2b6e994218f51a904 node-10 Configuring the Bare Metal Service Policy diff --git a/doc/source/admin/raid.rst b/doc/source/admin/raid.rst index 38753d6989..22e42c782f 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 ``openstack baremetal node validate ``. In-band RAID is +command ``baremetal node validate ``. 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 + baremetal driver raid property list Mandatory properties ^^^^^^^^^^^^^^^^^^^^ @@ -296,7 +296,7 @@ physical disk found on the bare metal node. To get the current RAID configuration:: - openstack baremetal node show + baremetal node show Workflow ======== @@ -314,12 +314,12 @@ Workflow `Target RAID configuration`_. The target RAID configuration is set on the Ironic node:: - openstack baremetal node set \ + baremetal node set \ --target-raid-config The CLI command can accept the input from standard input also:: - openstack baremetal node set \ + baremetal node set \ --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 \ + baremetal node clean \ --clean-steps * After manual cleaning is complete, the current RAID configuration is reported in the ``raid_config`` field when running:: - openstack baremetal node show + baremetal node show Software RAID ============= diff --git a/doc/source/admin/ramdisk-boot.rst b/doc/source/admin/ramdisk-boot.rst index cd6c2151ff..815321b0cb 100644 --- a/doc/source/admin/ramdisk-boot.rst +++ b/doc/source/admin/ramdisk-boot.rst @@ -26,7 +26,7 @@ be set upon creation of a new node: .. code-block:: shell - openstack baremetal node create --driver ipmi \ + baremetal node create --driver ipmi \ --deploy-interface ramdisk \ --boot-interface ipxe @@ -34,13 +34,13 @@ or update an existing node: .. code-block:: shell - openstack baremetal node set --deploy-interface ramdisk + baremetal node set --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 \ + baremetal node set \ --instance-info boot_iso=http://path/to/boot.iso - openstack baremetal node deploy + baremetal node deploy Limitations ----------- diff --git a/doc/source/admin/rescue.rst b/doc/source/admin/rescue.rst index 5509796f43..286207faf2 100644 --- a/doc/source/admin/rescue.rst +++ b/doc/source/admin/rescue.rst @@ -62,7 +62,7 @@ but an example of how to do this is outlined below: .. code-block:: console - openstack baremetal node set $NODE_UUID \ + baremetal node set $NODE_UUID \ --driver-info rescue_ramdisk=$RESCUE_INITRD_UUID \ --driver-info rescue_kernel=$RESCUE_VMLINUZ_UUID @@ -76,7 +76,7 @@ using ssh, as given below: .. code-block:: console - openstack baremetal node rescue $NODE_UUID \ + baremetal node rescue $NODE_UUID \ --rescue-password --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: diff --git a/doc/source/admin/retirement.rst b/doc/source/admin/retirement.rst index 0ff1782aa6..e4884e0f40 100644 --- a/doc/source/admin/retirement.rst +++ b/doc/source/admin/retirement.rst @@ -29,7 +29,7 @@ How to use When it is known that a node shall be retired, set the ``retired`` flag on the node with:: - openstack baremetal node set --retired node-001 + baremetal node set --retired node-001 This can be done irrespective of the state the node is in, so in particular while the node is ``active``. @@ -42,7 +42,7 @@ particular while the node is ``active``. Optionally, a reason can be specified when a node is retired, e.g.:: - openstack baremetal node set --retired node-001 \ + baremetal node set --retired node-001 \ --retired-reason "End of warranty for delivery abc123" Upon instance deletion, an ``active`` node with the ``retired`` flag @@ -55,10 +55,10 @@ accidental re-use of nodes tagged for removal from the fleet. In order to move these nodes to ``available`` none the less, the ``retired`` field needs to be removed first. This can be done via:: - openstack baremetal node unset --retired node-001 + baremetal node unset --retired node-001 In order to facilitate the identification of nodes marked for retirement, e.g. by other teams, ironic also allows to list all nodes which have the ``retired`` flag set:: - openstack baremetal node list --retired + baremetal node list --retired diff --git a/doc/source/admin/troubleshooting.rst b/doc/source/admin/troubleshooting.rst index 9eee6a919a..505e4d8719 100644 --- a/doc/source/admin/troubleshooting.rst +++ b/doc/source/admin/troubleshooting.rst @@ -24,25 +24,25 @@ A few things should be checked in this case: maintenance mode and not already used by an existing instance. Check with the following command:: - openstack baremetal node list --provision-state available --no-maintenance --unassociated + baremetal node list --provision-state available --no-maintenance --unassociated - If this command does not show enough nodes, use generic ``openstack baremetal + If this command does not show enough nodes, use generic ``baremetal node list`` to check other nodes. For example, nodes in ``manageable`` state should be made available:: - openstack baremetal node provide + baremetal node provide 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 + baremetal node maintenance unset 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 | grep -E '(power|management)\W*False' + baremetal node validate | 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 --fields properties + $ baremetal node show --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 --fields properties + $ baremetal node show --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 diff --git a/doc/source/admin/upgrade-to-hardware-types.rst b/doc/source/admin/upgrade-to-hardware-types.rst index 9fa6b7f5df..934dc412cd 100644 --- a/doc/source/admin/upgrade-to-hardware-types.rst +++ b/doc/source/admin/upgrade-to-hardware-types.rst @@ -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:: diff --git a/doc/source/contributor/deploy-steps.rst b/doc/source/contributor/deploy-steps.rst index 7fe5ce47e1..21022b2b11 100644 --- a/doc/source/contributor/deploy-steps.rst +++ b/doc/source/contributor/deploy-steps.rst @@ -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:: diff --git a/doc/source/contributor/dev-quickstart.rst b/doc/source/contributor/dev-quickstart.rst index 0e7e773f5a..e2a5fb441a 100644 --- a/doc/source/contributor/dev-quickstart.rst +++ b/doc/source/contributor/dev-quickstart.rst @@ -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 | +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ diff --git a/doc/source/contributor/drivers.rst b/doc/source/contributor/drivers.rst index 7c9caa1b41..bd1b4f7c35 100644 --- a/doc/source/contributor/drivers.rst +++ b/doc/source/contributor/drivers.rst @@ -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 ----------------------- diff --git a/doc/source/install/configdrive.rst b/doc/source/install/configdrive.rst index 3165e734c7..41240efe0d 100644 --- a/doc/source/install/configdrive.rst +++ b/doc/source/install/configdrive.rst @@ -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 ` +:python-ironicclient-doc:`baremetal client ` 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 diff --git a/doc/source/install/configure-ipv6-networking.rst b/doc/source/install/configure-ipv6-networking.rst index 79d7bbd0ca..0d9c4e0a4f 100644 --- a/doc/source/install/configure-ipv6-networking.rst +++ b/doc/source/install/configure-ipv6-networking.rst @@ -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 The use of multiple IPv6 addresses must also be enabled in the Networking diff --git a/doc/source/install/enrollment.rst b/doc/source/install/enrollment.rst index 1e0f9957e7..a60ab9408d 100644 --- a/doc/source/install/enrollment.rst +++ b/doc/source/install/enrollment.rst @@ -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 | +--------------+--------------------------------------+ diff --git a/doc/source/install/include/disk-label.inc b/doc/source/install/include/disk-label.inc index 6568db9b9b..9f6c153258 100644 --- a/doc/source/install/include/disk-label.inc +++ b/doc/source/install/include/disk-label.inc @@ -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 --property capabilities='disk_label:gpt' + baremetal node set --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 --instance-info capabilities='{"disk_label": "gpt"}' + baremetal node set --instance-info capabilities='{"disk_label": "gpt"}' diff --git a/doc/source/install/include/local-boot-partition-images.inc b/doc/source/install/include/local-boot-partition-images.inc index acb8a4aeeb..ddb13364e5 100644 --- a/doc/source/install/include/local-boot-partition-images.inc +++ b/doc/source/install/include/local-boot-partition-images.inc @@ -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 --property capabilities="boot_option:local" + baremetal node set --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 --instance-info capabilities='{"boot_option": "local"}' + baremetal node set --instance-info capabilities='{"boot_option": "local"}' diff --git a/doc/source/install/include/root-device-hints.inc b/doc/source/install/include/root-device-hints.inc index 76569f3b22..51452be35b 100644 --- a/doc/source/install/include/root-device-hints.inc +++ b/doc/source/install/include/root-device-hints.inc @@ -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 --property root_device='{"wwn": "0x4000cca77fc4dba1"}' + baremetal node set --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 --property root_device='{"size": ">= 60", "rotational": false}' + baremetal node set --property root_device='{"size": ">= 60", "rotational": false}' * Finding a disk whose vendor is ``samsung`` or ``winsys``:: - openstack baremetal node set --property root_device='{"vendor": " samsung winsys"}' + baremetal node set --property root_device='{"vendor": " samsung winsys"}' .. note:: If multiple hints are specified, a device must satisfy all the hints. diff --git a/doc/source/install/include/trusted-boot.inc b/doc/source/install/include/trusted-boot.inc index ac3a75d885..c720de5e5e 100644 --- a/doc/source/install/include/trusted-boot.inc +++ b/doc/source/install/include/trusted-boot.inc @@ -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:: diff --git a/doc/source/install/standalone.rst b/doc/source/install/standalone.rst index 00013c6ca5..8c80eb78a8 100644 --- a/doc/source/install/standalone.rst +++ b/doc/source/install/standalone.rst @@ -131,7 +131,7 @@ Using CLI --------- To use the -:python-ironicclient-doc:`openstack baremetal CLI `, +:python-ironicclient-doc:`baremetal CLI `, 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 ` 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 ` 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 ` 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:: diff --git a/doc/source/install/troubleshooting.rst b/doc/source/install/troubleshooting.rst index 2db7589871..75f19c729a 100644 --- a/doc/source/install/troubleshooting.rst +++ b/doc/source/install/troubleshooting.rst @@ -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