diff --git a/deploy-guide/source/features/baremetal_overcloud.rst b/deploy-guide/source/features/baremetal_overcloud.rst index 27392d67..e03ade4b 100644 --- a/deploy-guide/source/features/baremetal_overcloud.rst +++ b/deploy-guide/source/features/baremetal_overcloud.rst @@ -298,11 +298,11 @@ Check that Ironic works by connecting to the overcloud and trying to list the nodes (you should see an empty response, but not an error):: source overcloudrc - openstack baremetal node list + baremetal node list You can also check the enabled driver list:: - $ openstack baremetal driver list + $ baremetal driver list +---------------------+-------------------------+ | Supported driver(s) | Active host(s) | +---------------------+-------------------------+ @@ -318,7 +318,7 @@ You can also check the enabled driver list:: For HA configuration you should see all three controllers:: - $ openstack baremetal driver list + $ baremetal driver list +---------------------+------------------------------------------------------------------------------------------------------------+ | Supported driver(s) | Active host(s) | +---------------------+------------------------------------------------------------------------------------------------------------+ @@ -507,7 +507,7 @@ and/or ``rescuing_network`` to the ``driver_info`` dictionary when After enrolling nodes, you can update each of them with the following command (adjusting it for your release):: - openstack baremetal node set \ + baremetal node set \ --driver-info cleaning_network= \ --driver-info provisioning_network= \ --driver-info rescuing_network= @@ -746,12 +746,12 @@ The ``overcloud-nodes.yaml`` file prepared in the previous steps can now be imported in Ironic:: source overcloudrc - openstack baremetal create overcloud-nodes.yaml + baremetal create overcloud-nodes.yaml .. warning:: This command is provided by Ironic, not TripleO. It also does not feature support for updates, so if you need to change something, you have to use - ``openstack baremetal node set`` and similar commands. + ``baremetal node set`` and similar commands. The nodes appear in the ``enroll`` provision state, you need to check their BMC credentials and make them available:: @@ -759,15 +759,15 @@ credentials and make them available:: DEPLOY_KERNEL=$(openstack image show deploy-kernel -f value -c id) DEPLOY_RAMDISK=$(openstack image show deploy-ramdisk -f value -c id) - for uuid in $(openstack baremetal node list --provision-state enroll -f value -c UUID); + for uuid in $(baremetal node list --provision-state enroll -f value -c UUID); do - openstack baremetal node set $uuid \ + baremetal node set $uuid \ --driver-info deploy_kernel=$DEPLOY_KERNEL \ --driver-info deploy_ramdisk=$DEPLOY_RAMDISK \ --driver-info rescue_kernel=$DEPLOY_KERNEL \ --driver-info rescue_ramdisk=$DEPLOY_RAMDISK - openstack baremetal node manage $uuid --wait && - openstack baremetal node provide $uuid + baremetal node manage $uuid --wait && + baremetal node provide $uuid done The deploy kernel and ramdisk were created as part of `Adding deployment @@ -777,7 +777,7 @@ The ``baremetal node provide`` command makes a node go through cleaning procedure, so it might take some time depending on the configuration. Check your nodes status with:: - openstack baremetal node list --fields uuid name provision_state last_error + baremetal node list --fields uuid name provision_state last_error Wait for all nodes to reach the ``available`` state. Any failures during cleaning has to be corrected before proceeding with deployment. @@ -824,7 +824,7 @@ Check that nodes are really enrolled and the power state is reflected correctly (it may take some time):: $ source overcloudrc - $ openstack baremetal node list + $ baremetal node list +--------------------------------------+------------+---------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+------------+---------------+-------------+--------------------+-------------+ @@ -961,8 +961,8 @@ do this each baremetal node must first be configured to boot from a volume. The connector ID for each node should be unique, below we achieve this by incrementing the value of :: - $ openstack baremetal node set --property capabilities=iscsi_boot:true --storage-interface cinder - $ openstack baremetal volume connector create --node --type iqn --connector-id iqn.2010-10.org.openstack.node + $ baremetal node set --property capabilities=iscsi_boot:true --storage-interface cinder + $ baremetal volume connector create --node --type iqn --connector-id iqn.2010-10.org.openstack.node The image used should be configured to boot from a iSCSI root disk, on Centos 7 this is achieved by ensuring that the `iscsi` module is added to the ramdisk @@ -1134,7 +1134,7 @@ If not already provided in ``overcloud-nodes.yaml`` above, the local-link-connection values for `switch_info`, `port_id` and `switch_id` can be provided here:: - openstack baremetal port set --local-link-connection switch_info=switch1 \ + baremetal port set --local-link-connection switch_info=switch1 \ --local-link-connection port_id=xe-0/0/7 \ --local-link-connection switch_id=00:00:00:00:00:00 diff --git a/deploy-guide/source/features/deploy_cellv2_basic.rst b/deploy-guide/source/features/deploy_cellv2_basic.rst index 97352685..2b20a11e 100644 --- a/deploy-guide/source/features/deploy_cellv2_basic.rst +++ b/deploy-guide/source/features/deploy_cellv2_basic.rst @@ -225,7 +225,7 @@ Tag node into the new flavor using the following command .. code-block:: bash - openstack baremetal node set --property \ + baremetal node set --property \ capabilities='profile:cellcontroller,boot_option:local' Verify the tagged cellcontroller: diff --git a/deploy-guide/source/features/derived_parameters.rst b/deploy-guide/source/features/derived_parameters.rst index e7b6a2c8..26bace9f 100644 --- a/deploy-guide/source/features/derived_parameters.rst +++ b/deploy-guide/source/features/derived_parameters.rst @@ -127,7 +127,7 @@ be used later during deployment for servers in the ComputeHCI role. We will use this server's Ironic UUID so that the playbook gets its introspection data:: - [stack@undercloud ~]$ openstack baremetal node list | grep ceph-2 + [stack@undercloud ~]$ baremetal node list | grep ceph-2 | ef4cbd49-3773-4db2-80da-4210a7c24047 | ceph-2 | None | power off | available | False | [stack@undercloud ~]$ diff --git a/deploy-guide/source/features/distributed_compute_node.rst b/deploy-guide/source/features/distributed_compute_node.rst index 8020b748..21c24f78 100644 --- a/deploy-guide/source/features/distributed_compute_node.rst +++ b/deploy-guide/source/features/distributed_compute_node.rst @@ -275,7 +275,7 @@ setting below:: Existing nodes can be updated to use the ``direct`` deploy interface. For example:: - openstack baremetal node set --deploy-interface direct 4b64a750-afe3-4236-88d1-7bb88c962666 + baremetal node set --deploy-interface direct 4b64a750-afe3-4236-88d1-7bb88c962666 .. _deploy_control_plane: diff --git a/deploy-guide/source/features/node_specific_hieradata.rst b/deploy-guide/source/features/node_specific_hieradata.rst index 99bc973b..2a8b3f35 100644 --- a/deploy-guide/source/features/node_specific_hieradata.rst +++ b/deploy-guide/source/features/node_specific_hieradata.rst @@ -26,7 +26,7 @@ Ironic database. Then extract the machine unique UUID for the target node with a command like:: - openstack baremetal introspection data save NODE-ID | jq .extra.system.product.uuid | tr '[:upper:]' '[:lower:]' + baremetal introspection data save NODE-ID | jq .extra.system.product.uuid | tr '[:upper:]' '[:lower:]' where `NODE-ID` is the target node Ironic UUID. The value returned by the above command will be a unique and immutable machine UUID which isn't related to the @@ -70,8 +70,8 @@ introspection data. Export the introspection data from Ironic for the Ceph nodes to be deployed:: - openstack baremetal introspection data save oc0-ceph-0 > ceph0.json - openstack baremetal introspection data save oc0-ceph-1 > ceph1.json + baremetal introspection data save oc0-ceph-0 > ceph0.json + baremetal introspection data save oc0-ceph-1 > ceph1.json ... Copy the utility to the stack user's home directory on the undercloud @@ -80,11 +80,10 @@ be passed during openstack overcloud deployment:: ./make_ceph_disk_list.py -i ceph*.json -o node_data_lookup.json -k by_path -Pass the introspection data file from `openstack baremetal -introspection data save` for all nodes hosting Ceph OSDs to the -utility as you may only define `NodeDataLookup` once during a -deployment. The `-i` option can take an expression like `*.json` or a -list of files as input. +Pass the introspection data file from `baremetal introspection data save` for +all nodes hosting Ceph OSDs to the utility as you may only define +`NodeDataLookup` once during a deployment. The `-i` option can take an +expression like `*.json` or a list of files as input. The `-k` option defines the key of ironic disk data structure to use to identify the disk to be used as an OSD. Using `name` is not diff --git a/deploy-guide/source/features/routed_spine_leaf_network.rst b/deploy-guide/source/features/routed_spine_leaf_network.rst index 89e970ff..112db9c7 100644 --- a/deploy-guide/source/features/routed_spine_leaf_network.rst +++ b/deploy-guide/source/features/routed_spine_leaf_network.rst @@ -270,10 +270,10 @@ the ones used in the ``subnets`` option in the undercloud configuration. To set all nodes to ``manageable`` state run the following command:: - for node in $(openstack baremetal node list -f value -c Name); do \ - openstack baremetal node manage $node --wait; done + for node in $(baremetal node list -f value -c Name); do \ + baremetal node manage $node --wait; done -#. Use ``openstack baremetal port list --node `` command to find out +#. Use ``baremetal port list --node `` command to find out which baremetal ports are associated with which baremetal node. Then set the ``physical-network`` for the ports. @@ -283,11 +283,11 @@ the ones used in the ``subnets`` option in the undercloud configuration. the baremetal port connected to ``leaf0`` use ``ctlplane``. The remaining ports use the ``leafX`` names:: - $ openstack baremetal port set --physical-network ctlplane + $ baremetal port set --physical-network ctlplane - $ openstack baremetal port set --physical-network leaf1 - $ openstack baremetal port set --physical-network leaf2 - $ openstack baremetal port set --physical-network leaf2 + $ baremetal port set --physical-network leaf1 + $ baremetal port set --physical-network leaf2 + $ baremetal port set --physical-network leaf2 #. Make sure the nodes are in ``available`` state before deploying the overcloud:: diff --git a/deploy-guide/source/features/undercloud_minion.rst b/deploy-guide/source/features/undercloud_minion.rst index 59d7532e..2d65f1ec 100644 --- a/deploy-guide/source/features/undercloud_minion.rst +++ b/deploy-guide/source/features/undercloud_minion.rst @@ -138,11 +138,11 @@ Installation Steps undercloud:: source ~/stackrc - openstack baremetal conductor list + baremetal conductor list Example output:: - (undercloud) [stack@undercloud ~]$ openstack baremetal conductor list + (undercloud) [stack@undercloud ~]$ baremetal conductor list +------------------------+-----------------+-------+ | Hostname | Conductor Group | Alive | +------------------------+-----------------+-------+ diff --git a/deploy-guide/source/provisioning/ansible_deploy_interface.rst b/deploy-guide/source/provisioning/ansible_deploy_interface.rst index 40359c9f..786c8174 100644 --- a/deploy-guide/source/provisioning/ansible_deploy_interface.rst +++ b/deploy-guide/source/provisioning/ansible_deploy_interface.rst @@ -109,8 +109,8 @@ Configuring nodes Nodes have to be explicitly configured to use the Ansible deploy. For example, to configure all nodes, use:: - for node in $(openstack baremetal node list -f value -c UUID); do - openstack baremetal node set $node --deploy-interface ansible + for node in $(baremetal node list -f value -c UUID); do + baremetal node set $node --deploy-interface ansible done Editing playbooks @@ -149,8 +149,8 @@ nodes. #. Set the newly introduced ``kernel_params`` extra variable to the desired kernel parameters. For example, to update only compute nodes use:: - for node in $(openstack baremetal node list -c Name -f value | grep compute); do - openstack baremetal node set $node \ + for node in $(baremetal node list -c Name -f value | grep compute); do + baremetal node set $node \ --extra kernel_params='param1=value1 param2=value2' done diff --git a/deploy-guide/source/provisioning/baremetal_provision.rst b/deploy-guide/source/provisioning/baremetal_provision.rst index b4b4bd35..10ac090a 100644 --- a/deploy-guide/source/provisioning/baremetal_provision.rst +++ b/deploy-guide/source/provisioning/baremetal_provision.rst @@ -586,9 +586,9 @@ The overcloud can then be deployed using the output from the provision command:: Viewing Provisioned Node Details -------------------------------- -The commands ``openstack baremetal node list`` and ``openstack baremetal node -show`` continue to show the details of all nodes, however there are some new -commands which show a further view of the provisioned nodes. +The commands ``baremetal node list`` and ``baremetal node show`` continue to +show the details of all nodes, however there are some new commands which show a +further view of the provisioned nodes. The `metalsmith`_ tool provides a unified view of provisioned nodes, along with allocations and neutron ports. This is similar to what Nova provides when it @@ -600,11 +600,11 @@ managed by metalsmith, run:: The baremetal allocation API keeps an association of nodes to hostnames, which can be seen by running:: - openstack baremetal allocation list + baremetal allocation list The allocation record UUID will be the same as the Instance UUID for the node which is allocated. The hostname can be seen in the allocation record, but it -can also be seen in the ``openstack baremetal node show`` property +can also be seen in the ``baremetal node show`` property ``instance_info``, ``display_name``. diff --git a/deploy-guide/source/provisioning/cleaning.rst b/deploy-guide/source/provisioning/cleaning.rst index 030970a8..a56874e9 100644 --- a/deploy-guide/source/provisioning/cleaning.rst +++ b/deploy-guide/source/provisioning/cleaning.rst @@ -39,7 +39,7 @@ to wipe the node's metadata starting with the Rocky release: #. If the node is not in the ``manageable`` state, move it there:: - openstack baremetal node manage + baremetal node manage #. Run manual cleaning on a specific node:: diff --git a/deploy-guide/source/provisioning/introspect_single_node.rst b/deploy-guide/source/provisioning/introspect_single_node.rst index 0806cef4..65397ffd 100644 --- a/deploy-guide/source/provisioning/introspect_single_node.rst +++ b/deploy-guide/source/provisioning/introspect_single_node.rst @@ -3,21 +3,21 @@ Introspecting a Single Node In addition to bulk introspection, you can also introspect nodes one by one. When doing so, you must take care to set the correct node states manually. -Use ``openstack baremetal node show UUID`` command to figure out whether nodes +Use ``baremetal node show UUID`` command to figure out whether nodes are in ``manageable`` or ``available`` state. For all nodes in ``available`` state, start with putting a node to ``manageable`` state (see :doc:`node_states` for details):: - openstack baremetal node manage + baremetal node manage Then you can run introspection:: - openstack baremetal introspection start UUID + baremetal introspection start UUID This command won't poll for the introspection result, use the following command to check the current introspection state:: - openstack baremetal introspection status UUID + baremetal introspection status UUID Repeat it for every node until you see ``True`` in the ``finished`` field. The ``error`` field will contain an error message if introspection failed, @@ -25,4 +25,4 @@ or ``None`` if introspection succeeded for this node. Do not forget to make nodes available for deployment afterwards:: - openstack baremetal node provide + baremetal node provide diff --git a/deploy-guide/source/provisioning/introspection_data.rst b/deploy-guide/source/provisioning/introspection_data.rst index 333dc468..344d7e19 100644 --- a/deploy-guide/source/provisioning/introspection_data.rst +++ b/deploy-guide/source/provisioning/introspection_data.rst @@ -9,7 +9,7 @@ the hardware and puts them as JSON in Swift. Starting with ``python-ironic-inspector-client`` version 1.4.0 there is a command to retrieve this data:: - openstack baremetal introspection data save + baremetal introspection data save You can provide a ``--file`` argument to save the data in a file instead of displaying it. @@ -48,7 +48,7 @@ and use that to collect a list of node mac addresses:: export IRONIC_INSPECTOR_PASSWORD=xxxxxx # Download the extra introspection data from swift: - for node in $(openstack baremetal node list -f value -c UUID); + for node in $(baremetal node list -f value -c UUID); do swift -U service:ironic -K $IRONIC_INSPECTOR_PASSWORD download ironic-inspector extra_hardware-$node; done @@ -71,7 +71,7 @@ Extra data examples Here is an example of CPU extra data, including benchmark results:: - $ openstack baremetal introspection data save | jq '.extra.cpu' + $ baremetal introspection data save | jq '.extra.cpu' { "physical": { "number": 1 @@ -108,7 +108,7 @@ Here is an example of CPU extra data, including benchmark results:: Here is an example of disk extra data, including benchmark results:: - $ openstack baremetal introspection data save | jq '.extra.disk' + $ baremetal introspection data save | jq '.extra.disk' { "logical": { "count": 1 diff --git a/deploy-guide/source/provisioning/node_discovery.rst b/deploy-guide/source/provisioning/node_discovery.rst index 1bd618f1..98b7da7e 100644 --- a/deploy-guide/source/provisioning/node_discovery.rst +++ b/deploy-guide/source/provisioning/node_discovery.rst @@ -111,7 +111,7 @@ the discovery process: .. code-block:: console - openstack baremetal introspection rule import /path/to/rules.json + baremetal introspection rule import /path/to/rules.json See :doc:`profile_matching` for more examples on introspection rules. diff --git a/deploy-guide/source/provisioning/node_placement.rst b/deploy-guide/source/provisioning/node_placement.rst index 40184d65..836fe717 100644 --- a/deploy-guide/source/provisioning/node_placement.rst +++ b/deploy-guide/source/provisioning/node_placement.rst @@ -21,7 +21,7 @@ by the Nova scheduler on deployment. This can either be done via the nodes json file when registering the nodes, or alternatively via manual adjustment of the node capabilities, e.g:: - openstack baremetal node set --property capabilities='node:controller-0' + baremetal node set --property capabilities='node:controller-0' This has assigned the capability ``node:controller-0`` to the node, and this must be repeated (using a unique continuous index, starting from 0) for all diff --git a/deploy-guide/source/provisioning/node_states.rst b/deploy-guide/source/provisioning/node_states.rst index 14d01cd5..ace30176 100644 --- a/deploy-guide/source/provisioning/node_states.rst +++ b/deploy-guide/source/provisioning/node_states.rst @@ -37,7 +37,7 @@ The ``manage`` action can be used to bring nodes from enroll_ to ``manageable`` or nodes already moved to available_ state back to ``manageable`` for configuration:: - openstack baremetal node manage + baremetal node manage available --------- @@ -51,4 +51,4 @@ in this state. Nodes which failed introspection stay in ``manageable`` state and must be reintrospected or made ``available`` manually:: - openstack baremetal node provide + baremetal node provide diff --git a/deploy-guide/source/provisioning/ready_state.rst b/deploy-guide/source/provisioning/ready_state.rst index 61c9802b..460a0617 100644 --- a/deploy-guide/source/provisioning/ready_state.rst +++ b/deploy-guide/source/provisioning/ready_state.rst @@ -28,4 +28,4 @@ Make sure the nodes have profiles assigned as described in :doc:`profile_matching`. Create a JSON file with the target ready-state configuration for each profile. Then trigger the configuration:: - openstack baremetal configure ready state ready-state.json + baremetal configure ready state ready-state.json diff --git a/deploy-guide/source/provisioning/root_device.rst b/deploy-guide/source/provisioning/root_device.rst index 53074cae..edb9621d 100644 --- a/deploy-guide/source/provisioning/root_device.rst +++ b/deploy-guide/source/provisioning/root_device.rst @@ -11,17 +11,17 @@ for more details. For example:: - openstack baremetal node set --property root_device='{"wwn": "0x4000cca77fc4dba1"}' + baremetal node set --property root_device='{"wwn": "0x4000cca77fc4dba1"}' To remove a hint and fallback to the default behavior:: - openstack baremetal node unset --property root_device + baremetal node unset --property root_device Note that the root device hints should be assigned *before* both introspection and deployment. After changing the root device hints you should either re-run introspection or manually fix the ``local_gb`` property for a node:: - openstack baremetal node set --property local_gb= + baremetal node set --property local_gb= Where the new value is calculated as a real disk size in GiB minus 1 GiB to account for partitioning (the introspection process does this calculation @@ -61,7 +61,7 @@ introspection to figure it out. First start with :ref:`introspection` as usual without setting any root device hints. Then use the stored introspection data to list all disk devices:: - openstack baremetal introspection data save fdf975ae-6bd7-493f-a0b9-a0a4667b8ef3 | jq '.inventory.disks' + baremetal introspection data save fdf975ae-6bd7-493f-a0b9-a0a4667b8ef3 | jq '.inventory.disks' For **python-ironic-inspector-client** versions older than 1.4.0 you can use the ``curl`` command instead, see :ref:`introspection_data` for details. diff --git a/deploy-guide/source/provisioning/uefi_boot.rst b/deploy-guide/source/provisioning/uefi_boot.rst index 12ac93bf..0efee34c 100644 --- a/deploy-guide/source/provisioning/uefi_boot.rst +++ b/deploy-guide/source/provisioning/uefi_boot.rst @@ -44,19 +44,19 @@ configure introspected nodes to deploy in UEFI mode as well. Here is how the ``properties`` field looks for nodes configured in BIOS mode:: - $ openstack baremetal node show -f value -c properties + $ baremetal node show -f value -c properties {u'capabilities': u'profile:compute,boot_mode:bios', u'memory_mb': u'6144', u'cpu_arch': u'x86_64', u'local_gb': u'49', u'cpus': u'1'} Note that ``boot_mode:bios`` capability is set. For a node in UEFI mode, it will look like this:: - $ openstack baremetal node show -f value -c properties + $ baremetal node show -f value -c properties {u'capabilities': u'profile:compute,boot_mode:uefi', u'memory_mb': u'6144', u'cpu_arch': u'x86_64', u'local_gb': u'49', u'cpus': u'1'} You can change the boot mode with the following command (required for UEFI before the Pike release):: - $ openstack baremetal node set --property capabilities=profile:compute,boot_mode:uefi + $ baremetal node set --property capabilities=profile:compute,boot_mode:uefi .. warning:: Do not forget to copy all other capabilities, e.g. ``profile`` and diff --git a/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst b/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst index 9816f63e..75112471 100644 --- a/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst +++ b/deploy-guide/source/troubleshooting/troubleshooting-nodes.rst @@ -60,16 +60,16 @@ For example, a wrong MAC can be fixed in two steps: * Find out the assigned port UUID by running :: - $ openstack baremetal port list --node + $ baremetal port list --node * Update the MAC address by running :: - $ openstack baremetal port set --address + $ baremetal port set --address A Wrong IPMI address can be fixed with the following command:: - $ openstack baremetal node set --driver-info ipmi_address= + $ baremetal node set --driver-info ipmi_address= Node power state is not enforced by Ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -103,7 +103,7 @@ power management, and it gets stuck in an abnormal state. Ironic requires that nodes that cannot be operated normally are put in the maintenance mode. It is done by the following command:: - $ openstack baremetal node maintenance set --reason "" + $ baremetal node maintenance set --reason "" Ironic will stop checking power and health state for such nodes, and Nova will not pick them for deployment. Power command will still work on them, though. @@ -112,11 +112,11 @@ After a node is in the maintenance mode, you can attempt repairing it, e.g. by `Fixing invalid node information`_. If you manage to make the node operational again, move it out of the maintenance mode:: - $ openstack baremetal node maintenance unset + $ baremetal node maintenance unset If repairing is not possible, you can force deletion of such node:: - $ openstack baremetal node delete + $ baremetal node delete Forcing node removal will leave it powered on, accessing the network with the old IP address(es) and with all services running. Before proceeding, make @@ -189,4 +189,4 @@ How can introspection be stopped? Introspection for a node can be stopped with the following command:: - $ openstack baremetal introspection abort + $ baremetal introspection abort diff --git a/deploy-guide/source/troubleshooting/troubleshooting-overcloud.rst b/deploy-guide/source/troubleshooting/troubleshooting-overcloud.rst index d371cb7f..0c909f93 100644 --- a/deploy-guide/source/troubleshooting/troubleshooting-overcloud.rst +++ b/deploy-guide/source/troubleshooting/troubleshooting-overcloud.rst @@ -31,7 +31,7 @@ Next, there are a few layers on which the deployment can fail: * Post-deploy configuration (Puppet) As Ironic service is in the middle layer, you can use its shell to guess the -failed layer. Issue ``openstack baremetal node list`` command to see all +failed layer. Issue ``baremetal node list`` command to see all registered nodes and their current status, you will see something like:: +--------------------------------------+------+---------------+-------------+-----------------+-------------+ @@ -50,7 +50,7 @@ in the resulting table. You can check the actual cause using the following command:: - $ openstack baremetal node show -f value -c maintenance_reason + $ baremetal node show -f value -c maintenance_reason For example, **Maintenance** goes to ``True`` automatically, if wrong power credentials are provided. @@ -58,7 +58,7 @@ in the resulting table. Fix the cause of the failure, then move the node out of the maintenance mode:: - $ openstack baremetal node maintenance unset + $ baremetal node maintenance unset * If **Provision State** is ``available`` then the problem occurred before bare metal deployment has even started. Proceed with `Debugging Using Heat`_. @@ -75,7 +75,7 @@ in the resulting table. * If **Provision State** is ``error`` or ``deploy failed``, then bare metal deployment has failed for this node. Look at the **last_error** field:: - $ openstack baremetal node show -f value -c last_error + $ baremetal node show -f value -c last_error If the error message is vague, you can use logs to clarify it, see :ref:`ironic_logs` for details. @@ -266,7 +266,7 @@ you have enough nodes corresponding to each flavor/profile. Watch :: - $ openstack baremetal node show --fields properties + $ baremetal node show --fields properties It should contain e.g. ``profile:compute`` for compute nodes. diff --git a/doc/source/install/advanced_deployment/deploy_openshift.rst b/doc/source/install/advanced_deployment/deploy_openshift.rst index 03de83cc..e0eba46b 100644 --- a/doc/source/install/advanced_deployment/deploy_openshift.rst +++ b/doc/source/install/advanced_deployment/deploy_openshift.rst @@ -305,7 +305,7 @@ of your OpenShift nodes. .. code-block:: bash - openstack baremetal node list + baremetal node list 2. Locate the OpenShift node: