Chapter 11. Provisioning and deploying your overcloud

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Copy the sample network definition template you require from /usr/share/openstack-tripleo-heat-templates/network-data-samples to your environment file directory:

   (undercloud)$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml

3. Configure your network definition file for your network environment. For example, you can update the external network definition:

   - name: External
     name_lower: external
     vip: true
     mtu: 1500
     subnets:
       external_subnet:
         ip_subnet: 10.0.0.0/24
         allocation_pools:
           - start: 10.0.0.4
             end: 10.0.0.250
         gateway_ip: 10.0.0.1
         vlan: 10

4. Configure any other networks and network attributes for your environment. For more information about the properties you can use to configure network attributes in your network definition file, see Configuring overcloud networking.

5. Provision the overcloud networks:

   (undercloud)$ openstack overcloud network provision \
    [--templates <templates_directory> \]
    --output  <deployment_file> \
    /home/stack/templates/<networks_definition_file>

   • Optional: Include the --templates option to use your own templates instead of the default templates located in /usr/share/openstack-tripleo-heat-templates. Replace <templates_directory> with the path to the directory that contains your templates.
   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-networks-deployed.yaml.
   • Replace <networks_definition_file> with the name of your networks definition file, for example, network_data.yaml.

6. When network provisioning is complete, you can use the following commands to check the created networks and subnets:

   (undercloud)$ openstack network list
   (undercloud)$ openstack subnet list
   (undercloud)$ openstack network show <network>
   (undercloud)$ openstack subnet show <subnet>

   • Replace <network> with the name or UUID of the network you want to check.
   • Replace <subnet> with the name or UUID of the subnet you want to check.

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Copy the sample network VIP definition template you require from /usr/share/openstack-tripleo-heat-templates/network-data-samples to your environment file directory:

   (undercloud)$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml /home/stack/templates/vip_data.yaml

3. Optional: Configure your VIP definition file for your environment. For example, the following defines the external network and control plane VIPs:

   - network: external
     dns_name: overcloud
   - network: ctlplane
     dns_name: overcloud

4. Configure any other network VIP attributes for your environment. For more information about the properties you can use to configure VIP attributes in your VIP definition file, see Adding a composable network.

5. Provision the network VIPs:

   (undercloud)$ openstack overcloud network vip provision \
    [--templates <templates_directory> \]
    --stack <stack> \
    --output <deployment_file> \
    /home/stack/templates/<vip_definition_file>

   • Optional: Include the --templates option to use your own templates instead of the default templates located in /usr/share/openstack-tripleo-heat-templates. Replace <templates_directory> with the path to the directory that contains your templates.
   • Replace <stack> with the name of the stack for which the network VIPs are provisioned, for example, overcloud.
   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-vip-deployed.yaml.
   • Replace <vip_definition_file> with the name of your VIP definition file, for example, vip_data.yaml.

6. When the network VIP provisioning is complete, you can use the following commands to check the created VIPs:

   (undercloud)$ openstack port list
   (undercloud)$ openstack port show <port>

   • Replace <port> with the name or UUID of the port you want to check.

Procedure

1. Create a template named nodes.json or nodes.yaml that lists your nodes. Use the following JSON and YAML template examples to understand how to structure your node definition template:

   Example JSON template

   {
     "nodes": [{
       "name": "node01",
       "ports": [{
         "address": "aa:aa:aa:aa:aa:aa",
         "physical_network": "ctlplane",
         "local_link_connection": {
           "switch_id": "52:54:00:00:00:00",
           "port_id": "p0"
         }
       }],
       "cpu": "4",
       "memory": "6144",
       "disk": "40",
       "arch": "x86_64",
       "pm_type": "ipmi",
       "pm_user": "admin",
       "pm_password": "p@55w0rd!",
       "pm_addr": "192.168.24.205"
     },
     {
       "name": "node02",
       "ports": [{
         "address": "bb:bb:bb:bb:bb:bb",
         "physical_network": "ctlplane",
         "local_link_connection": {
           "switch_id": "52:54:00:00:00:00",
           "port_id": "p0"
         }
       }],
       "cpu": "4",
       "memory": "6144",
       "disk": "40",
       "arch": "x86_64",
       "pm_type": "ipmi",
       "pm_user": "admin",
       "pm_password": "p@55w0rd!",
       "pm_addr": "192.168.24.206"
     }]
   }

   Example YAML template

   nodes:
     - name: "node01"
       ports:
         - address: "aa:aa:aa:aa:aa:aa"
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.205"
     - name: "node02"
       ports:
         - address: "bb:bb:bb:bb:bb:bb"
           physical_network: ctlplane
           local_link_connection:
             switch_id: 52:54:00:00:00:00
             port_id: p0
       cpu: 4
       memory: 6144
       disk: 40
       arch: "x86_64"
       pm_type: "ipmi"
       pm_user: "admin"
       pm_password: "p@55w0rd!"
       pm_addr: "192.168.24.206"

   This template contains the following attributes:

   name

   The logical name for the node.

   ports

   The port to access the specific IPMI device. You can define the following optional port attributes:

   • address: The MAC address for the network interface on the node. Use only the MAC address for the Provisioning NIC of each system.
   • physical_network: The physical network that is connected to the Provisioning NIC.
   • local_link_connection: If you use IPv6 provisioning and LLDP does not correctly populate the local link connection during introspection, you must include fake data with the switch_id and port_id fields in the local_link_connection parameter. For more information on how to include fake data, see Using director introspection to collect bare metal node hardware information.

   cpu

   (Optional) The number of CPUs on the node.

   memory

   (Optional) The amount of memory in MB.

   disk

   (Optional) The size of the hard disk in GB.

   arch

   (Optional) The system architecture.

   pm_type

   The power management driver that you want to use. This example uses the IPMI driver (ipmi).

   Note

   IPMI is the preferred supported power management driver. For more information about supported power management types and their options, see Power management drivers. If these power management drivers do not work as expected, use IPMI for your power management.

   pm_user; pm_password

   The IPMI username and password.

   pm_addr

   The IP address of the IPMI device.

2. Verify the template formatting and syntax:

   $ source ~/stackrc
   (undercloud)$ openstack overcloud node import --validate-only ~/nodes.json

3. Save the template file to the home directory of the stack user (/home/stack/nodes.json).

4. Import the template to director to register each node from the template into director:

   (undercloud)$ openstack overcloud node import ~/nodes.json

5. Wait for the node registration and configuration to complete. When complete, confirm that director has successfully registered the nodes:

   (undercloud)$ openstack baremetal node list

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Create the overcloud-baremetal-deploy.yaml node definition file and define the node count for each role that you want to provision. For example, to provision three Controller nodes and three Compute nodes, add the following configuration to your overcloud-baremetal-deploy.yaml file:

   - name: Controller
     count: 3
   - name: Compute
     count: 3

3. Optional: Configure predictive node placements. For example, use the following configuration to provision three Controller nodes on nodes node00, node01, and node02, and three Compute nodes on node04, node05, and node06:

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02
   - name: Compute
     count: 3
     instances:
     - hostname: overcloud-novacompute-0
       name: node04
     - hostname: overcloud-novacompute-1
       name: node05
     - hostname: overcloud-novacompute-2
       name: node06

4. Optional: By default, the provisioning process uses the overcloud-hardened-uefi-full.qcow2 image. You can change the image used on specific nodes, or the image used for all nodes for a role, by specifying the local or remote URL for the image. The following examples change the image to a local QCOW2 image:

   Specific nodes

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
       image:
         href: file:///var/lib/ironic/images/overcloud-custom.qcow2
     - hostname: overcloud-controller-1
       name: node01
       image:
         href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
     - hostname: overcloud-controller-2
       name: node02
       image:
         href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2

   All nodes for a role

   - name: Controller
     count: 3
     defaults:
       image:
         href: file:///var/lib/ironic/images/overcloud-custom.qcow2
     instances:
     - hostname: overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02

5. Define the network layout for all nodes for a role, or the network layout for specific nodes:

   Specific nodes

   The following example provisions the networks for a specific Controller node, and allocates a predictable IP to the node for the Internal API network:

   - name: Controller
     count: 3
     defaults:
       network_config:
         template: /home/stack/templates/nic-config/myController.j2
         default_route_network:
         - external
       instances:
         - hostname: overcloud-controller-0
           name: node00
           networks:
             - network: ctlplane
               vif: true
             - network: external
               subnet: external_subnet
             - network: internal_api
               subnet: internal_api_subnet01
               fixed_ip: 172.21.11.100
             - network: storage
               subnet: storage_subnet01
             - network: storage_mgmt
               subnet: storage_mgmt_subnet01
             - network: tenant
               subnet: tenant_subnet01

   All nodes for a role

   The following example provisions the networks for the Controller and Compute roles:

   - name: Controller
     count: 3
     defaults:
       networks:
       - network: ctlplane
         vif: true
       - network: external
         subnet: external_subnet
       - network: internal_api
         subnet: internal_api_subnet01
       - network: storage
         subnet: storage_subnet01
       - network: storage_mgmt
         subnet: storage_mgmt_subnet01
       - network: tenant
         subnet: tenant_subnet01
       network_config:
         template: /home/stack/templates/nic-config/myController.j2 1
         default_route_network:
         - external
   - name: Compute
     count: 3
     defaults:
       networks:
       - network: ctlplane
         vif: true
       - network: internal_api
         subnet: internal_api_subnet02
       - network: tenant
         subnet: tenant_subnet02
       - network: storage
         subnet: storage_subnet02
       network_config:
         template: /home/stack/templates/nic-config/myCompute.j2

   1

   You can use the example NIC templates located in /usr/share/ansible/roles/tripleo_network_config/templates to create your own NIC templates in your local environment file directory.

6. Optional: Configure the disk partition size allocations if the default disk partition sizes do not meet your requirements. For example, the default partition size for the /var/log partition is 10 GB. Consider your log storage and retention requirements to determine if 10 GB meets your requirements. If you need to increase the allocated disk size for your log storage, add the following configuration to your node definition file to override the defaults:

   ansible_playbooks:
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
       extra_vars:
         role_growvols_args:
           default:
             /=8GB
             /tmp=1GB
             /var/log=<log_size>GB
             /var/log/audit=2GB
             /home=1GB
             /var=100%

   • Replace <log_size> with the size of the disk to allocate to log files.
7. If you use the Object Storage service (swift) and the whole disk overcloud image, overcloud-hardened-uefi-full, you need to configure the size of the /srv partition based on the size of your disk and your storage requirements for /var and /srv. For more information, see Configuring whole disk partitions for the Object Storage service.
8. Optional: Designate the overcloud nodes for specific roles by using custom resource classes or the profile capability. For more information, see Designating overcloud nodes for roles by matching resource classes and Designating overcloud nodes for roles by matching profiles.
9. Define any other attributes that you want to assign to your nodes. For more information about the properties you can use to configure node attributes in your node definition file, see Bare metal node provisioning attributes. For an example node definition file, see Example node definition file.

10. Provision the overcloud nodes:

    (undercloud)$ openstack overcloud node provision \
     [--templates <templates_directory> \]
     --stack <stack> \
     --network-config \
     --output <deployment_file> \
     /home/stack/templates/<node_definition_file>

    • Optional: Include the --templates option to use your own templates instead of the default templates located in /usr/share/openstack-tripleo-heat-templates. Replace <templates_directory> with the path to the directory that contains your templates.
    • Replace <stack> with the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is overcloud.
    • Include the --network-config optional argument to provide the network definitions to the cli-overcloud-node-network-config.yaml Ansible playbook.
    • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-baremetal-deployed.yaml.
    • Replace <node_definition_file> with the name of your node definition file, for example, overcloud-baremetal-deploy.yaml.

11. Monitor the provisioning progress in a separate terminal:

    (undercloud)$ watch openstack baremetal node list

    • When provisioning is successful, the node state changes from available to active.
    • If the node provisioning fails because of a node hardware or network configuration failure, then you can remove the failed node before running the provisioning step again. For more information, see Removing failed bare-metal nodes from the node definition file.

12. Use the metalsmith tool to obtain a unified view of your nodes, including allocations and ports:

    (undercloud)$ metalsmith list

13. Verify the association of nodes to hostnames:

    (undercloud)$ openstack baremetal allocation list

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Open your overcloud-baremetal-deploy.yaml node definition file.

3. Decrement the count parameter for the role that the node is allocated to. For example, the following configuration updates the count parameter for the ObjectStorage role to reflect that the number of nodes dedicated to ObjectStorage is reduced to 3:

   - name: ObjectStorage
     count: 3

4. Define the hostname and name of the node that you want to remove from the stack, if it is not already defined in the instances attribute for the role.

5. Add the attribute provisioned: false to the node that you want to remove. For example, to remove the node overcloud-objectstorage-1 from the stack, include the following snippet in your overcloud-baremetal-deploy.yaml file:

   - name: ObjectStorage
     count: 3
     instances:
     - hostname: overcloud-objectstorage-0
       name: node00
     - hostname: overcloud-objectstorage-1
       name: node01
       # Removed from cluster due to disk failure
       provisioned: false
     - hostname: overcloud-objectstorage-2
       name: node02
     - hostname: overcloud-objectstorage-3
       name: node03

6. Unprovision the bare-metal nodes:

   (undercloud)$ openstack overcloud node unprovision \
    --stack <stack> \
    --network-ports \
    /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <stack> with the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is overcloud.

7. Provision the overcloud nodes to generate an updated heat environment file for inclusion in the deployment command:

   (undercloud)$ openstack overcloud node provision \
   --stack <stack> \
   --output <deployment_file> \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-baremetal-deployed.yaml.

Procedure

1. Assign each bare metal node that you want to designate for a role with a custom resource class:

   (undercloud)$ openstack baremetal node set \
    --resource-class <resource_class> <node>

   • Replace <resource_class> with a name for the resource class, for example, baremetal.CPU-PINNING.
   • Replace <node> with the ID of the bare metal node.
2. Add the role to your overcloud-baremetal-deploy.yaml file, if not already defined.

3. Specify the resource class that you want to assign to the nodes for the role:

   - name: <role>
     count: 1
     defaults:
       resource_class: <resource_class>

   • Replace <role> with the name of the role.
   • Replace <resource_class> with the name you specified for the resource class in step 1.
4. Return to Provisioning bare metal nodes for the overcloud to complete the provisioning process.

Procedure

1. Existing node capabilities are overwritten each time you add a new node capability. Therefore, you must retrieve the existing capabilities of each registered node in order to set them again:

   $ openstack baremetal node show <node> \
    -f json -c properties | jq -r .properties.capabilities

2. Assign the profile capability to each bare metal node that you want to match to a role profile, by adding profile:<profile> to the existing capabilities of the node:

   (undercloud)$ openstack baremetal node set  <node> \
    --property capabilities="profile:<profile>,<capability_1>,...,<capability_n>"

   • Replace <node> with the name or ID of the bare metal node.
   • Replace <profile> with the name of the profile that matches the role profile.
   • Replace <capability_1>, and all capabilities up to <capability_n>, with each capability that you retrieved in step 1.
3. Add the role to your overcloud-baremetal-deploy.yaml file, if not already defined.

4. Define the profile that you want to assign to the nodes for the role:

   - name: <role>
     count: 1
     defaults:
       profile: <profile>

   • Replace <role> with the name of the role.
   • Replace <profile> with the name of the profile that matches the node capability.
5. Return to Provisioning bare metal nodes for the overcloud to complete the provisioning process.

Procedure

1. Configure the /srv and /var partitions by using role_growvols_args as an extra Ansible variable in the Ansible_playbooks definition in your overcloud-baremetal-deploy.yaml node definition file. Set either /srv or /var to an absolute size in GB, and set the other to 100% to consume the remaining disk space.

   • The following example configuration sets /srv to an absolute size for the Object Storage service deployed on the Controller node, and /var to 100% to consume the remaining disk space:

     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
         extra_vars:
           role_growvols_args:
             default:
               /=8GB
               /tmp=1GB
               /var/log=10GB
               /var/log/audit=2GB
               /home=1GB
               /var=100%
             Controller:
               /=8GB
               /tmp=1GB
               /var/log=10GB
               /var/log/audit=2GB
               /home=1GB
               /srv=50GB
               /var=100%

   • The following example configuration sets /var to an absolute size, and /srv to 100% to consume the remaining disk space of the Object Storage node for the Object Storage service:

     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-growvols.yaml
         extra_vars:
           role_growvols_args:
             default:
               /=8GB
               /tmp=1GB
               /var/log=10GB
               /var/log/audit=2GB
               /home=1GB
               /var=100%
            ObjectStorage:
               /=8GB
               /tmp=1GB
               /var/log=10GB
               /var/log/audit=2GB
               /home=1GB
               /var=10GB
               /srv=100%

2. Return to Provisioning bare metal nodes for the overcloud to complete the provisioning process.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Set the Bare Metal Provisioning service boot interface to redfish-virtual-media:

   (undercloud)$ openstack baremetal node set --boot-interface redfish-virtual-media <node>

   • Replace <node> with the name of the node.

4. Define the ESP image:

   (undercloud)$ openstack baremetal node set --driver-info bootloader=<esp> <node>

   • Replace <esp> with the Image service (glance) image UUID or the URL for the ESP image.
   • Replace <node> with the name of the node.

5. Create a port on the bare-metal node and associate the port with the MAC address of the NIC on the bare-metal node:

   (undercloud)$ openstack baremetal port create --pxe-enabled True \
    --node <node_uuid> <mac_address>

   • Replace <node_uuid> with the UUID of the bare-metal node.
   • Replace <mac_address> with the MAC address of the NIC on the bare-metal node.

Procedure

1. Verify the disk information from the hardware introspection of each node:

   (undercloud)$ openstack baremetal introspection data save <node_uuid> | --file <output_file_name>

   • Replace <node_uuid> with the UUID of the node.

   • Replace <output_file_name> with the name of the file that contains the output of the node introspection.

     For example, the data for one node might show three disks:

     [
       {
         "size": 299439751168,
         "rotational": true,
         "vendor": "DELL",
         "name": "/dev/sda",
         "wwn_vendor_extension": "0x1ea4dcc412a9632b",
         "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
         "model": "PERC H330 Mini",
         "wwn": "0x61866da04f380700",
         "serial": "61866da04f3807001ea4dcc412a9632b"
       }
       {
         "size": 299439751168,
         "rotational": true,
         "vendor": "DELL",
         "name": "/dev/sdb",
         "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
         "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
         "model": "PERC H330 Mini",
         "wwn": "0x61866da04f380d00",
         "serial": "61866da04f380d001ea4e13c12e36ad6"
       }
       {
         "size": 299439751168,
         "rotational": true,
         "vendor": "DELL",
         "name": "/dev/sdc",
         "wwn_vendor_extension": "0x1ea4e31e121cfb45",
         "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
         "model": "PERC H330 Mini",
         "wwn": "0x61866da04f37fc00",
         "serial": "61866da04f37fc001ea4e31e121cfb45"
       }
     ]

2. Set the root disk for the node by using a unique hardware property:

   (undercloud)$ openstack baremetal node set --property root_device='{<property_value>}' <node-uuid>

   • Replace <property_value> with the unique hardware property value from the introspection data to use to set the root disk.

   • Replace <node_uuid> with the UUID of the node.

     Note

     A unique hardware property is any property from the hardware introspection step that uniquely identifies the disk. For example, the following command uses the disk serial number to set the root disk:

     (undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

3. Configure the BIOS of each node to first boot from the network and then the root disk.

Procedure

1. Open your overcloud-baremetal-deploy.yaml file.

2. Add or update the image property for the nodes that you want to use the overcloud-minimal image. You can set the image to overcloud-minimal on specific nodes, or for all nodes for a role:

   Specific nodes

   - name: Ceph
     count: 3
     instances:
     - hostname: overcloud-ceph-0
       name: node00
       image:
         href: file:///var/lib/ironic/images/overcloud-minimal.qcow2
     - hostname: overcloud-ceph-1
       name: node01
       image:
         href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2
     - hostname: overcloud-ceph-2
       name: node02
       image:
         href: file:///var/lib/ironic/images/overcloud-full-custom.qcow2

   All nodes for a role

   - name: Ceph
     count: 3
     defaults:
       image:
         href: file:///var/lib/ironic/images/overcloud-minimal.qcow2
     instances:
     - hostname: overcloud-ceph-0
       name: node00
     - hostname: overcloud-ceph-1
       name: node01
     - hostname: overcloud-ceph-2
       name: node02

3. In the roles_data.yaml role definition file, set the rhsm_enforce parameter to False.

   rhsm_enforce: False

4. Run the provisioning command:

   (undercloud)$ openstack overcloud node provision \
   --stack stack \
   --output /home/stack/templates/overcloud-baremetal-deployed.yaml \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

5. Pass the overcloud-baremetal-deployed.yaml environment file to the openstack overcloud deploy command.

1. Modify parameters in the custom environment files and heat templates.
2. Run the openstack overcloud deploy command again with the same environment files.

Procedure

1. Open the certificate file and copy only the certificate portion. Do not include the key:

   $ vi /home/stack/ca.crt.pem

   The certificate portion you need looks similar to this shortened example:

   -----BEGIN CERTIFICATE-----
   MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
   BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
   UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
   -----END CERTIFICATE-----

2. Create a new YAML file called /home/stack/inject-trust-anchor-hiera.yaml with the following contents, and include the certificate you copied from the PEM file:

   parameter_defaults:
     CAMap:
       undercloud-ca:
         content: |
           -----BEGIN CERTIFICATE-----
           MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
           BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
           UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
           -----END CERTIFICATE-----

   Note
   • The certificate string must follow the PEM format.
   • The CAMap parameter might contain other certificates relevant to SSL/TLS configuration.
3. Add the /home/stack/inject-trust-anchor-hiera.yaml file to your deployment command. Director copies the CA certificate to each overcloud node during the overcloud deployment. As a result, each node trusts the encryption presented by the undercloud’s SSL endpoints.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Update your overcloud stack with all the environment files your deployment requires:

   $ openstack overcloud deploy --templates \
     -e environment-file1.yaml \
     -e environment-file2.yaml \
     ...
     --stack-only

4. Validate your overcloud stack:

   $ validation run \
     --group pre-deployment \
     --inventory <inventory_file>

   • Replace <inventory_file> with the name and location of the Ansible inventory file, for example, ~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml.
   Note

   When you run a validation, the Reasons column in the output is limited to 79 characters. To view the validation result in full, view the validation log files.

5. Review the results of the validation report:

   $ validation history get [--full] [--validation-log-dir <log_dir>] <uuid>

   • Optional: Use the --full option to view detailed output from the validation run.
   • Optional: Use the --validation-log-dir option to write the output from the validation run to the validation logs.
   • Replace <uuid> with the UUID of the validation run.

Procedure

1. Collate the environment files and configuration files that you need for your overcloud environment, both the unedited heat template files provided with your director installation, and the custom environment files you created. This should include the following files:

   • overcloud-baremetal-deployed.yaml node definition file.
   • overcloud-networks-deployed.yaml network definition file.
   • overcloud-vip-deployed.yaml network VIP definition file.
   • The location of the container images for containerized OpenStack services.
   • Any environment files for Red Hat CDN or Satellite registration.
   • Any other custom environment files.
2. Organize the environment files and configuration files by their order of precedence, listing unedited heat template files first, followed by your environment files that contain custom configuration, such as overrides to the default properties.

3. Construct your openstack overcloud deploy command, specifying the configuration files and templates in the required order, for example:

   (undercloud) $ openstack overcloud deploy --templates \
    [-n /home/stack/templates/network_data.yaml \ ]
     -e /home/stack/templates/overcloud-baremetal-deployed.yaml\
     -e /home/stack/templates/overcloud-networks-deployed.yaml\
     -e /home/stack/templates/overcloud-vip-deployed.yaml \
     -e /home/stack/containers-prepare-parameter.yaml \
     -e /home/stack/inject-trust-anchor-hiera.yaml \
    [-r /home/stack/templates/roles_data.yaml ]

   -n /home/stack/templates/network_data.yaml

   Specifies the custom network configuration. Required if you use network isolation or custom composable networks. For information on configuring overcloud networks, see Configuring overcloud networking.

   -e /home/stack/containers-prepare-parameter.yaml

   Adds the container image preparation environment file. You generated this file during the undercloud installation and can use the same file for your overcloud creation.

   -e /home/stack/inject-trust-anchor-hiera.yaml

   Adds an environment file to install a custom certificate in the undercloud.

   -r /home/stack/templates/roles_data.yaml

   The generated roles data, if you use custom roles or want to enable a multi-architecture cloud.

4. When the overcloud creation completes, director provides a recap of the Ansible plays that were executed to configure the overcloud:

   PLAY RECAP *************************************************************
   overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
   overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
   undercloud              : ok=10   changed=7    unreachable=0    failed=0
   
   Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
   ========================================================================

5. When the overcloud creation completes, director provides details to access your overcloud:

   Ansible passed.
   Overcloud configuration completed.
   Overcloud Endpoint: http://192.168.24.113:5000
   Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
   Overcloud rc file: /home/stack/overcloudrc
   Overcloud Deployed

Procedure

1. Source the stackrc credentials file:

   $ source ~/stackrc

2. Validate your overcloud deployment:

   $ validation run \
     --group post-deployment \
     [--inventory <inventory_file>]

   • Replace <inventory_file> with the name of your ansible inventory file. By default, the dynamic inventory is called tripleo-ansible-inventory.

     Note

     When you run a validation, the Reasons column in the output is limited to 79 characters. To view the validation result in full, view the validation log files.

3. Review the results of the validation report:

   $ validation show run [--full] <UUID>

   • Replace <UUID> with the UUID of the validation run.
   • Optional: Use the --full option to view detailed output from the validation run.

Procedure

1. Source the overcloudrc file:

   (undercloud)$ source ~/overcloudrc

   The command prompt changes to indicate that you are accessing the overcloud:

   (overcloud)$

2. To return to interacting with the undercloud, source the stackrc file:

   (overcloud)$ source ~/stackrc
   (undercloud)$

   The command prompt changes to indicate that you are accessing the undercloud:

   (undercloud)$

Procedure

1. On each overcloud node, create the stack user and set a password. For example, run the following commands on the Controller node:

   [root@controller-0 ~]# useradd stack
   [root@controller-0 ~]# passwd stack  # specify a password

2. Disable password requirements for this user when using sudo:

   [root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
   [root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack

3. After you create and configure the stack user on all pre-provisioned nodes, copy the stack user’s public SSH key from the director node to each overcloud node. For example, to copy the director’s public SSH key to the Controller node, run the following command:

   [stack@director ~]$ ssh-copy-id stack@192.168.24.2

Procedure

1. Run the registration command and enter your Customer Portal user name and password when prompted:

   [root@controller-0 ~]# sudo subscription-manager register

2. Find the entitlement pool for Red Hat OpenStack Platform 17.0:

   [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"

3. Use the pool ID located in the previous step to attach the Red Hat OpenStack Platform 16 entitlements:

   [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id

4. Disable all default repositories:

   [root@controller-0 ~]# sudo subscription-manager repos --disable=*

5. Enable the required Red Hat Enterprise Linux repositories:

   [root@controller-0 ~]# sudo subscription-manager repos \
    --enable=rhel-9-for-x86_64-baseos-eus-rpms \
    --enable=rhel-9-for-x86_64-appstream-eus-rpms \
    --enable=rhel-9-for-x86_64-highavailability-eus-rpms \
    --enable=openstack-beta-for-rhel-9-x86_64-rpms \
    --enable=fast-datapath-for-rhel-9-x86_64-rpms

6. If the overcloud uses Ceph Storage nodes, enable the relevant Ceph Storage repositories:

   [root@cephstorage-0 ~]# sudo subscription-manager repos \
    --enable=rhel-9-for-x86_64-baseos-rpms \
    --enable=rhel-9-for-x86_64-appstream-rpms \
    --enable=openstack-beta-deployment-tools-for-rhel-9-x86_64-rpms

7. Lock the RHEL version on all overcloud nodes except Red Hat Ceph Storage nodes:

   [root@controller-0 ~]# sudo subscription-manager release --set=9.0

8. Update your system to ensure you have the latest base system packages:

   [root@controller-0 ~]# sudo dnf update -y
   [root@controller-0 ~]# sudo reboot

Procedure

1. Copy the certificate authority file to the /etc/pki/ca-trust/source/anchors/ directory on each pre-provisioned node.

2. Run the following command on each overcloud node:

   [root@controller-0 ~]#  sudo update-ca-trust extract

Procedure

1. Create an environment file, for example hostname-map.yaml, and include the HostnameMap parameter and the hostname mappings. Use the following syntax:

   parameter_defaults:
     HostnameMap:
       [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
       [HEAT HOSTNAME]: [ACTUAL HOSTNAME]

   The [HEAT HOSTNAME] usually conforms to the following convention: [STACK NAME]-[ROLE]-[INDEX]:

   parameter_defaults:
     HostnameMap:
       overcloud-controller-0: controller-00-rack01
       overcloud-controller-1: controller-01-rack02
       overcloud-controller-2: controller-02-rack03
       overcloud-novacompute-0: compute-00-rack01
       overcloud-novacompute-1: compute-01-rack01
       overcloud-novacompute-2: compute-02-rack01

2. Save the hostname-map.yaml file.

Procedure

1. On the undercloud host, create an environment variable, OVERCLOUD_HOSTS, and set the variable to a space-separated list of IP addresses of the overcloud hosts that you want to use as Ceph clients:

   export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"

2. The default overcloud plan name is overcloud. If you use a different name, create an environment variable OVERCLOUD_PLAN to store your custom name:

   export OVERCLOUD_PLAN="<custom-stack-name>"

   • Replace <custom-stack-name> with the name of your stack.

3. Run the enable-ssh-admin.sh script to configure a user on the overcloud nodes that Ansible can use to configure Ceph clients:

   bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

Procedure

1. Source the overcloudrc file:

   (undercloud)$ source ~/overcloudrc

   The command prompt changes to indicate that you are accessing the overcloud:

   (overcloud)$

2. To return to interacting with the undercloud, source the stackrc file:

   (overcloud)$ source ~/stackrc
   (undercloud)$

   The command prompt changes to indicate that you are accessing the undercloud:

   (undercloud)$

1. Prepare the new pre-provisioned nodes according to Section 11.4.1, “Pre-provisioned node requirements”.
2. Scale up the nodes. For more information, see Chapter 19, Scaling overcloud nodes.
3. After you execute the deployment command, wait until the director creates the new node resources and launches the configuration.

1. Identify the name of the node that you want to remove.

   $ openstack stack resource list overcloud -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

2. Pass the corresponding node name from the stack_name column to the openstack overcloud node delete command:

   $ openstack overcloud node delete --stack <overcloud> <stack>

   • Replace <overcloud> with the name or UUID of the overcloud stack.
   • Replace <stack_name> with the name of the node that you want to remove. You can include multiple node names in the openstack overcloud node delete command.

3. Ensure that the openstack overcloud node delete command runs to completion:

   $ openstack stack list

   The status of the overcloud stack shows UPDATE_COMPLETE when the delete operation is complete.