Director Installation and Usage

Procedure

1. Log in to your undercloud as the root user.

2. Create the stack user:

   [root@director ~]# useradd stack

3. Set a password for the user:

   [root@director ~]# passwd stack

4. Disable password requirements when using sudo:

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

5. Switch to the new stack user:

   [root@director ~]# su - stack
   [stack@director ~]$

6. Create directories for system images and heat templates:

   [stack@director ~]$ mkdir ~/images
   [stack@director ~]$ mkdir ~/templates

   Director uses system images and heat templates to create the overcloud environment. Red Hat recommends creating these directories to help you organize your local file system.

7. Check the base and full hostname of the undercloud:

   [stack@director ~]$ hostname
   [stack@director ~]$ hostname -f

   If either of the previous commands do not report the correct fully-qualified hostname or report an error, use hostnamectl to set a hostname:

   [stack@director ~]$ sudo hostnamectl set-hostname undercloud.example.com
   [stack@director ~]$ sudo hostnamectl set-hostname --transient undercloud.example.com

8. If you are not using a DNS server that can resolve the fully qualified domain name (FQDN) of the undercloud host, edit the /etc/hosts and include an entry for the system hostname. The IP address in /etc/hosts must match the address that you plan to use for your undercloud public API. For example, if the system uses undercloud.example.com as the FQDN and uses 10.0.0.1 for its IP address, add the following line to the /etc/hosts file:

   10.0.0.1  undercloud.example.com undercloud

9. If you plan for the Red Hat OpenStack Platform director to be on a separate domain than the overcloud or its identity provider, then you must add the additional domains to /etc/resolv.conf:

   search overcloud.com idp.overcloud.com

Procedure

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

2. Register your system either with the Red Hat Content Delivery Network or with a Red Hat Satellite. For example, run the following command to register the system to the Content Delivery Network. Enter your Customer Portal user name and password when prompted:

   [stack@director ~]$ sudo subscription-manager register

3. Find the entitlement pool ID for Red Hat OpenStack Platform (RHOSP) director:

   [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

4. Locate the Pool ID value and attach the Red Hat OpenStack Platform 16.1 entitlement:

   [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

5. Lock the undercloud to Red Hat Enterprise Linux 8.2:

   $ sudo subscription-manager release --set=8.2

Procedure

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

2. Disable all default repositories, and enable the required Red Hat Enterprise Linux repositories:

   [stack@director ~]$ sudo subscription-manager repos --disable=*
   [stack@director ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-tus-rpms --enable=rhel-8-for-x86_64-appstream-tus-rpms --enable=rhel-8-for-x86_64-highavailability-tus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-eus-rpms

   These repositories contain packages that the director installation requires.

3. Set the container-tools repository module to version 2.0:

   [stack@director ~]$ sudo dnf module reset container-tools
   [stack@director ~]$ sudo dnf module enable -y container-tools:2.0

4. Perform an update on your system to ensure that you have the latest base system packages:

   [stack@director ~]$ sudo dnf update -y
   [stack@director ~]$ sudo reboot

Procedure

1. Install the command line tools for director installation and configuration:

   [stack@director ~]$ sudo dnf install -y python3-tripleoclient

Procedure

1. Enable the Ceph Tools repository:

   [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

2. Install the ceph-ansible package:

   [stack@director ~]$ sudo dnf install -y ceph-ansible

Procedure

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

2. Generate the default container image preparation file:

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   This command includes the following additional options:

   • --local-push-destination sets the registry on the undercloud as the location for container images. This means that director pulls the necessary images from the Red Hat Container Catalog and pushes them to the registry on the undercloud. Director uses this registry as the container image source. To pull directly from the Red Hat Container Catalog, omit this option.

   • --output-env-file is an environment file name. The contents of this file include the parameters for preparing your container images. In this case, the name of the file is containers-prepare-parameter.yaml.

     Note

     You can use the same containers-prepare-parameter.yaml file to define a container image source for both the undercloud and the overcloud.

3. Modify the containers-prepare-parameter.yaml to suit your requirements.

Procedure

1. Edit the containers-prepare-parameter.yaml file to exclude the Ceph Storage containers:

   parameter_defaults:
     ContainerImagePrepare:
     - push_destination: true
       excludes:
         - ceph
         - prometheus
       set:
         …​

   The excludes parameter uses regular expressions to exclude any container images that contain the ceph or prometheus strings.

2. Save the containers-prepare-parameter.yaml file.

Procedure

1. The following example runs the custom Dockerfile on the nova-compute image:

   ContainerImagePrepare:
   - push_destination: true
     ...
     includes:
     - nova-compute
     modify_role: tripleo-modify-image
     modify_append_tag: "-hotfix"
     modify_vars:
       tasks_from: modify_image.yml
       modify_dir_path: /home/stack/nova-custom
     ...

2. The following example shows the /home/stack/nova-custom/Dockerfile file. After you run any USER root directives, you must switch back to the original image default user:

   FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
   
   USER "root"
   
   COPY customize.sh /tmp/
   RUN /tmp/customize.sh
   
   USER "nova"

Procedure

1. Create a list of all container images:

   $ sudo podman search --limit 1000 "registry.redhat.io/rhosp-rhel8/openstack" --format="{{ .Name }}" | sort > satellite_images
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-dashboard-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/rhceph" | grep rhceph-4-rhel8
   $ sudo podman search --limit 1000 "registry.redhat.io/openshift" | grep ose-prometheus

   • If you plan to install Ceph and enable the Ceph Dashboard, you need the following ose-prometheus containers:

     registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
     registry.redhat.io/openshift4/ose-prometheus:v4.6
     registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6

2. Copy the satellite_images file to a system that contains the Satellite 6 hammer tool. Alternatively, use the instructions in the Hammer CLI Guide to install the hammer tool to the undercloud.

3. Run the following hammer command to create a new product (OSP16.1 Containers) in your Satellite organization:

   $ hammer product create \
     --organization "ACME" \
     --name "OSP Containers"

   This custom product will contain your images.

4. Add the overcloud container images from the satellite_images file:

   $ while read IMAGE; do \
     IMAGE_NAME=$(echo $IMAGE | cut -d"/" -f3 | sed "s/openstack-//g") ; \
     IMAGE_NOURL=$(echo $IMAGE | sed "s/registry.redhat.io\///g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE_NOURL \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name $IMAGE_NAME ; done < satellite_images

5. Add the Ceph Storage 4 container image:

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph/rhceph-4-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-4-rhel8

   Note

   If you want to install the Ceph dashboard, include --name rhceph-4-dashboard-rhel8 in the hammer repository create command:

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhceph/rhceph-4-dashboard-rhel8 \
     --upstream-username USERNAME \
     --upstream-password PASSWORD \
     --name rhceph-4-dashboard-rhel8

6. Synchronize the container images:

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP Containers"

   Wait for the Satellite server to complete synchronization.

   Note

   Depending on your configuration, hammer might ask for your Satellite server username and password. You can configure hammer to automatically login using a configuration file. For more information, see the Authentication section in the Hammer CLI Guide.

7. If your Satellite 6 server uses content views, create a new content view version to incorporate the images and promote it along environments in your application life cycle. This largely depends on how you structure your application lifecycle. For example, if you have an environment called production in your lifecycle and you want the container images to be available in that environment, create a content view that includes the container images and promote that content view to the production environment. For more information, see Managing Content Views.

8. Check the available tags for the base image:

   $ hammer docker tag list --repository "base" \
     --organization "ACME" \
     --lifecycle-environment "production" \
     --product "OSP Containers"

   This command displays tags for the OpenStack Platform container images within a content view for a particular environment.

9. Return to the undercloud and generate a default environment file that prepares images using your Satellite server as a source. Run the following example command to generate the environment file:

   $ sudo openstack tripleo container image prepare default \
     --output-env-file containers-prepare-parameter.yaml

   • --output-env-file is an environment file name. The contents of this file include the parameters for preparing your container images for the undercloud. In this case, the name of the file is containers-prepare-parameter.yaml.

10. Edit the containers-prepare-parameter.yaml file and modify the following parameters:

    • push_destination - Set this to true or false depending on your chosen container image management strategy. If you set this parameter to false, the overcloud nodes pull images directly from the Satellite. If you set this parameter to true, the director pulls the images from the Satellite to the undercloud registry and the overcloud pulls the images from the undercloud registry.
    • namespace - The URL and port of the registry on the Satellite server. The default registry port on Red Hat Satellite is 443.

    • name_prefix - The prefix is based on a Satellite 6 convention. This differs depending on whether you use content views:

      • If you use content views, the structure is [org]-[environment]-[content view]-[product]-. For example: acme-production-myosp16-osp_containers-.
      • If you do not use content views, the structure is [org]-[product]-. For example: acme-osp_containers-.
    • ceph_namespace, ceph_image, ceph_tag - If you use Ceph Storage, include these additional parameters to define the Ceph Storage container image location. Note that ceph_image now includes a Satellite-specific prefix. This prefix is the same value as the name_prefix option.

Procedure

1. Copy the default template to the home directory of the stack user’s:

   [stack@director ~]$ cp \
     /usr/share/python-tripleoclient/undercloud.conf.sample \
     ~/undercloud.conf

2. Edit the undercloud.conf file. This file contains settings to configure your undercloud. If you omit or comment out a parameter, the undercloud installation uses the default value.

Procedure

1. Create an environment file named /home/stack/templates/custom-undercloud-params.yaml.

2. Edit this file and include your heat parameters. For example, to enable debugging for certain OpenStack Platform services include the following snippet in the custom-undercloud-params.yaml file:

   parameter_defaults:
     Debug: True

   Save this file when you have finished.

3. Edit your undercloud.conf file and scroll to the custom_env_files parameter. Edit the parameter to point to your custom-undercloud-params.yaml environment file:

   custom_env_files = /home/stack/templates/custom-undercloud-params.yaml

   Note

   You can specify multiple environment files using a comma-separated list.

Procedure

1. Create a hieradata override file, for example, /home/stack/hieradata.yaml.

2. Add the customized hieradata to the file. For example, add the following snippet to modify the Compute (nova) service parameter force_raw_images from the default value of True to False:

   nova::compute::force_raw_images: False

   If there is no Puppet implementation for the parameter you want to set, then use the following method to configure the parameter:

   nova::config::nova_config:
     DEFAULT/<parameter_name>:
       value: <parameter_value>

   For example:

   nova::config::nova_config:
     DEFAULT/network_allocate_retries:
       value: 20
     ironic/serial_console_state_timeout:
       value: 15

3. Set the hieradata_override parameter in the undercloud.conf file to the path of the new /home/stack/hieradata.yaml file:

   hieradata_override = /home/stack/hieradata.yaml

Procedure

1. Open your undercloud.conf file.

2. Specify the IPv6 address mode as either stateless or stateful:

   [DEFAULT]
   ipv6_address_mode = <address_mode>
   ...

   • Replace <address_mode> with dhcpv6-stateless or dhcpv6-stateful, based on the mode that your NIC supports.
   Note

   When you use the stateful address mode, the firmware, chain loaders, and operating systems might use different algorithms to generate an ID that the DHCP server tracks. DHCPv6 does not track addresses by MAC, and does not provide the same address back if the identifier value from the requester changes but the MAC address remains the same. Therefore, when you use stateful DHCPv6 you must also complete the next step to configure the network interface.

3. If you configured your undercloud to use stateful DHCPv6, specify the network interface to use for bare metal nodes:

   [DEFAULT]
   ipv6_address_mode = dhcpv6-stateful
   ironic_enabled_network_interfaces = neutron,flat
   ...

4. Set the default network interface for bare metal nodes:

   [DEFAULT]
   ...
   ironic_default_network_interface = neutron
   ...

5. Specify whether or not the undercloud should create a router on the provisioning network:

   [DEFAULT]
   ...
   enable_routed_networks: <true/false>
   ...

   • Replace <true/false> with true to enable routed networks and prevent the undercloud creating a router on the provisioning network. When true, the data center router must provide router advertisements.
   • Replace <true/false> with false to disable routed networks and create a router on the provisioning network.

6. Configure the local IP address, and the IP address for the director Admin API and Public API endpoints over SSL/TLS:

   [DEFAULT]
   ...
   local_ip = <ipv6_address>
   undercloud_admin_host = <ipv6_address>
   undercloud_public_host = <ipv6_address>
   ...

   • Replace <ipv6_address> with the IPv6 address of the undercloud.

7. Optional: Configure the provisioning network that director uses to manage instances:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   ...

   • Replace <ipv6_address> with the IPv6 address of the network to use for managing instances when not using the default provisioning network.
   • Replace <ipv6_prefix> with the IP address prefix of the network to use for managing instances when not using the default provisioning network.

8. Configure the DHCP allocation range for provisioning nodes:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   ...

   • Replace <ipv6_address_dhcp_start> with the IPv6 address of the start of the network range to use for the overcloud nodes.
   • Replace <ipv6_address_dhcp_end> with the IPv6 address of the end of the network range to use for the overcloud nodes.

9. Optional: Configure the gateway for forwarding traffic to the external network:

   [ctlplane-subnet]
   cidr = <ipv6_address>/<ipv6_prefix>
   dhcp_start = <ipv6_address_dhcp_start>
   dhcp_end = <ipv6_address_dhcp_end>
   gateway = <ipv6_gateway_address>
   ...

   • Replace <ipv6_gateway_address> with the IPv6 address of the gateway when not using the default gateway.

10. Configure the DHCP range to use during the inspection process:

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    ...

    • Replace <ipv6_address_inspection_start> with the IPv6 address of the start of the network range to use during the inspection process.
    • Replace <ipv6_address_inspection_end> with the IPv6 address of the end of the network range to use during the inspection process.
    Note

    This range must not overlap with the range defined by dhcp_start and dhcp_end, but must be in the same IP subnet.

11. Configure an IPv6 nameserver for the subnet:

    [ctlplane-subnet]
    cidr = <ipv6_address>/<ipv6_prefix>
    dhcp_start = <ipv6_address_dhcp_start>
    dhcp_end = <ipv6_address_dhcp_end>
    gateway = <ipv6_gateway_address>
    inspection_iprange = <ipv6_address_inspection_start>,<ipv6_address_inspection_end>
    dns_nameservers = <ipv6_dns>

    • Replace <ipv6_dns> with the DNS nameservers specific to the subnet.

Procedure

1. Log in to the undercloud host.

2. Create a new file undercloud-os-net-config.yaml and include the network configuration that you require.

   For more information, see Network interface reference.

   Here is an example:

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers: 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     members:
     - type: interface
       name: nic2

   To create a network bond for a specific interface, use the following sample:

   network_config:
   - name: br-ctlplane
     type: ovs_bridge
     use_dhcp: false
     dns_servers: 192.168.122.1
     domain: lab.example.com
     ovs_extra:
     - "br-set-external-id br-ctlplane bridge-id br-ctlplane"
     addresses:
     - ip_netmask: 172.20.0.1/26
     members:
     - name: bond-ctlplane
       type: linux_bond
       use_dhcp: false
       bonding_options: "mode=active-backup"
       mtu: 1500
       members:
       - type: interface
         name: nic2
       - type: interface
         name: nic3

3. Include the path to the undercloud-os-net-config.yaml file in the net_config_override parameter in the undercloud.conf file:

   [DEFAULT]
   ...
   net_config_override=undercloud-os-net-config.yaml
   ...

   Note

   Director uses the file that you include in the net_config_override parameter as the template to generate the /etc/os-net-config/config.yaml file. os-net-config manages the interfaces that you define in the template, so you must perform all undercloud network interface customization in this file.

4. Install the undercloud.

Procedure

1. Run the following command to install director on the undercloud:

   [stack@director ~]$ openstack undercloud install

   This command launches the director configuration script. Director installs additional packages, configures its services according to the configuration in the undercloud.conf, and starts all the RHOSP service containers. This script takes several minutes to complete.

   The script generates two files:

   • undercloud-passwords.conf - A list of all passwords for the director services.
   • stackrc - A set of initialization variables to help you access the director command line tools.

2. Confirm that the RHOSP service containers are running:

   [stack@director ~]$ sudo podman ps -a --format "{{.Names}} {{.Status}}"

   The following command output indicates that the RHOSP service containers are running (Up):

   memcached Up 3 hours (healthy)
   haproxy Up 3 hours
   rabbitmq Up 3 hours (healthy)
   mysql Up 3 hours (healthy)
   iscsid Up 3 hours (healthy)
   keystone Up 3 hours (healthy)
   keystone_cron Up 3 hours (healthy)
   neutron_api Up 3 hours (healthy)
   logrotate_crond Up 3 hours (healthy)
   neutron_dhcp Up 3 hours (healthy)
   neutron_l3_agent Up 3 hours (healthy)
   neutron_ovs_agent Up 3 hours (healthy)
   ironic_api Up 3 hours (healthy)
   ironic_conductor Up 3 hours (healthy)
   ironic_neutron_agent Up 3 hours (healthy)
   ironic_pxe_tftp Up 3 hours (healthy)
   ironic_pxe_http Up 3 hours (unhealthy)
   ironic_inspector Up 3 hours (healthy)
   ironic_inspector_dnsmasq Up 3 hours (healthy)
   neutron-dnsmasq-qdhcp-30d628e6-45e6-499d-8003-28c0bc066487 Up 3 hours
   ...

3. To initialize the stack user to use the command line tools, run the following command:

   [stack@director ~]$ source ~/stackrc

   The prompt now indicates that OpenStack commands authenticate and execute against the undercloud;

   (undercloud) [stack@director ~]$

Procedure

1. Source the stackrc file to enable the director command line tools:

   [stack@director ~]$ source ~/stackrc

2. Set the nameservers for the ctlplane-subnet subnet:

   (undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet

   Use the --dns-nameserver option for each nameserver.

3. View the subnet to verify the nameserver:

   (undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet
   +-------------------+-----------------------------------------------+
   | Field             | Value                                         |
   +-------------------+-----------------------------------------------+
   | ...               |                                               |
   | dns_nameservers   | 8.8.8.8                                       |
   | ...               |                                               |
   +-------------------+-----------------------------------------------+

Procedure

1. Modify the undercloud configuration files. For example, edit the undercloud.conf file and add the idrac hardware type to the list of enabled hardware types:

   enabled_hardware_types = ipmi,redfish,idrac

2. Run the openstack undercloud install command to refresh your undercloud with the new changes:

   [stack@director ~]$ openstack undercloud install

   Wait until the command runs to completion.

3. Initialize the stack user to use the command line tools,:

   [stack@director ~]$ source ~/stackrc

   The prompt now indicates that OpenStack commands authenticate and execute against the undercloud:

   (undercloud) [stack@director ~]$

4. Verify that director has applied the new configuration. For this example, check the list of enabled hardware types:

   (undercloud) [stack@director ~]$ openstack baremetal driver list
   +---------------------+----------------------+
   | Supported driver(s) | Active host(s)       |
   +---------------------+----------------------+
   | idrac               | director.example.com |
   | ipmi                | director.example.com |
   | redfish             | director.example.com |
   +---------------------+----------------------+

Procedure

1. Log in to the minion host as the root user.

2. Create the stack user:

   [root@minion ~]# useradd stack

3. Set a password for the stack user:

   [root@minion ~]# passwd stack

4. Disable password requirements when using sudo:

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

5. Switch to the new stack user:

   [root@minion ~]# su - stack
   [stack@minion ~]$

6. Check the base and full hostname of the minion:

   [stack@minion ~]$ hostname
   [stack@minion ~]$ hostname -f

   If either of the previous commands do not report the correct fully-qualified hostname or report an error, use hostnamectl to set a hostname:

   [stack@minion ~]$ sudo hostnamectl set-hostname minion.example.com
   [stack@minion ~]$ sudo hostnamectl set-hostname --transient minion.example.com

7. Edit the /etc/hosts file and include an entry for the system hostname. For example, if the system is named minion.example.com and uses the IP address 10.0.0.1, add the following line to the /etc/hosts file:

   10.0.0.1  minion.example.com manager

8. Register your system either with the Red Hat Content Delivery Network or Red Hat Satellite. For example, run the following command to register the system to the Content Delivery Network. Enter your Customer Portal user name and password when prompted:

   [stack@minion ~]$ sudo subscription-manager register

9. Find the entitlement pool ID for Red Hat OpenStack Platform (RHOSP) director:

   [stack@minion ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
                        Red Hat Virtualization
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             Valid-Pool-Number-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

10. Locate the Pool ID value and attach the Red Hat OpenStack Platform 16.1 entitlement:

    [stack@minion ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456

11. Disable all default repositories, and then enable the required Red Hat Enterprise Linux repositories:

    [stack@minion ~]$ sudo subscription-manager repos --disable=*
    [stack@minion ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms

    These repositories contain packages that the minion installation requires.

12. Perform an update on your system to ensure that you have the latest base system packages:

    [stack@minion ~]$ sudo dnf update -y
    [stack@minion ~]$ sudo reboot

13. Install the command line tools for minion installation and configuration:

    [stack@minion ~]$ sudo dnf install -y python3-tripleoclient

Procedure

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

2. Copy the files from the undercloud to the minion:

   $ scp ~/tripleo-undercloud-outputs.yaml ~/tripleo-undercloud-passwords.yaml stack@<minion-host>:~/.

   • Replace <minion-host> with the hostname or IP address of the minion.

Procedure

1. Log in to the minion host as the root user.

2. Copy the certificate authority file from the undercloud to the minion:

   [root@minion ~]# scp \
       root@<undercloud-host>:/etc/pki/ca-trust/source/anchors/cm-local-ca.pem \
       /etc/pki/ca-trust/source/anchors/undercloud-ca.pem

   • Replace <undercloud-host> with the hostname or IP address of the undercloud.

3. Update the trusted certificate authorities for the minion host:

   [root@minion ~]# update-ca-trust enable
   [root@minion ~]# update-ca-trust extract

Procedure

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

2. Copy the default template to the home directory of the stack user:

   [stack@minion ~]$ cp \
     /usr/share/python-tripleoclient/minion.conf.sample \
     ~/minion.conf

3. Edit the minion.conf file. This file contains settings to configure your minion. If you omit or comment out a parameter, the minion installation uses the default value. Review the following recommended parameters:

   • minion_hostname, which you set to the hostname of the minion.
   • minion_local_interface, which you set to the interface that connects to the undercloud through the Provisioning Network.
   • minion_local_ip, which you set to a free IP address on the Provisioning Network.
   • minion_nameservers, which you set to the DNS nameservers so that the minion can resolve hostnames.
   • enable_ironic_conductor, which defines whether to enable the ironic-conductor service.
   • enable_heat_engine, which defines whether to enable the heat-engine service.

Procedure

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

2. Run the following command to install the minion:

   [stack@minion ~]$ openstack undercloud minion install

   This command launches the configuration script for the minion, installs additional packages, and configures minion services according to the configuration in the minion.conf file. This script takes several minutes to complete.

Procedure

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

2. Source the stackrc file:

   [stack@director ~]$ source ~/stackrc

3. If you enabled the heat engine service on the minion, verify that the heat-engine service from the minion appears on the undercloud service list:

   [stack@director ~]$ $ openstack orchestration service list

   The command output displays a table with heat-engine workers for both the undercloud and any minions.

4. If you enabled the ironic conductor service on the minion, verify that the ironic-conductor service from the minion appears on the undercloud service list:

   [stack@director ~]$ $ openstack baremetal conductor list

   The command output displays a table with ironic-conductor services for both the undercloud and any minions.

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": [{
   			"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"
   				}
   			}],
   			"name": "node01",
   			"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"
   		},
   		{
   			"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"
   				}
   			}],
   			"name": "node02",
   			"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:
     - 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
       name: "node01"
       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"
     - 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
       name: "node02"
       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.

   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 Chapter 30, 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.

   pm_port (Optional)

   The port to access the specific IPMI device.

   address

   (Optional) A list of MAC addresses for the network interfaces on the node. Use only the MAC address for the Provisioning NIC of each system.

   physical_network

   (Optional) The physical network that is connected to the Provisioning NIC.

   local_link_connection

   (Optional) 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.

   Important

   When building a multi-architecture cloud, the arch key is mandatory to distinguish nodes using x86_64 and ppc64le architectures.

2. After you create the template, run the following commands to verify the formatting and syntax:

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

   Important

   You must also include the --http-boot /var/lib/ironic/tftpboot/ option for multi-architecture nodes.

3. Save the file to the home directory of the stack user (/home/stack/nodes.json), then run the following commands to import the template to director:

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

   This command registers each node from the template into director. If you use UEFI boot mode, you must also set the boot mode on each node. If you introspect your nodes without setting UEFI boot mode, the nodes boot in legacy mode. For more information, see Setting the boot mode to UEFI boot mode.

4. 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. To tag a node into a specific profile, add a profile option to the properties/capabilities parameter for each node. For example, to tag a specific node to use a specific profile, use the following commands:

   (undercloud) $ NODE=<NODE NAME OR ID>
   (undercloud) $ PROFILE=<PROFILE NAME>
   (undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local" $NODE

   • Set the $NODE variable to the name or UUID of the node.
   • Set the $PROFILE variable to the specific profile, such as control or compute.
   • The profile option in properties/capabilities includes the $PROFILE variable to tag the node with the corresponding profile, such as profile:control or profile:compute.
   • Set the boot_option:local option to define how each node boots.

   You can also retain existing capabilities values using an additional openstack baremetal node show command and jq filtering:

   (undercloud) $ openstack baremetal node set --property capabilities="profile:$PROFILE,boot_option:local,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

2. After you complete node tagging, check the assigned profiles or possible profiles:

   (undercloud) $ openstack overcloud profiles list

Procedure

1. Set the following parameters in your undercloud.conf file:

   ipxe_enabled = True

2. Save the undercloud.conf file and run the undercloud installation:

   $ openstack undercloud install

   Wait until the installation script completes.

3. Check the existing capabilities of each registered node:

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

   • Replace <node> with the ID of the bare metal node.

4. Set the boot mode to uefi for each registered node by adding boot_mode:uefi to the existing capabilities of the node:

   $ openstack baremetal node set --property capabilities="boot_mode:uefi,<capability_1>,...,<capability_n>" <node>

   • Replace <node> with the ID of the bare metal node.

   • Replace <capability_1>, and all capabilities up to <capability_n>, with each capability that you retrieved in step 3.

     For example, use the following command to set the boot mode to uefi with local boot:

   $ openstack baremetal node set --property capabilities="boot_mode:uefi,boot_option:local" <node>

5. Set the boot mode to uefi for each bare metal flavor:

   $ openstack flavor set --property capabilities:boot_mode='uefi' <flavor>

Procedure

1. Set the Bare Metal service (ironic) boot interface to redfish-virtual-media:

   $ openstack baremetal node set --boot-interface redfish-virtual-media $NODE_NAME

   • Replace $NODE_NAME with the name of the node.

2. For UEFI nodes, set the boot mode to uefi:

   NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE

   • Replace $NODE with the name of the node.

     Note

     For BIOS nodes, do not complete this step.

3. For UEFI nodes, define the EFI System Partition (ESP) image:

   $ openstack baremetal node set --driver-info bootloader=$ESP $NODE_NAME

   • Replace $ESP with the glance image UUID or URL for the ESP image, and replace $NODE_NAME with the name of the node.

     Note

     For BIOS nodes, do not complete this step.

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

   $ openstack baremetal port create --pxe-enabled True --node $UUID $MAC_ADDRESS

   • Replace $UUID with the UUID of the bare metal node, and 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. The following command to displays the disk information of a node:

   (undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

   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. On the undercloud, set the root disk for a node. Include the most appropriate hardware attribute value to define the root disk.

   (undercloud)$ openstack baremetal node set --property root_device='{"serial":"<serial_number>"}' <node-uuid>

   For example, to set the root device to disk 2, which has the serial number 61866da04f380d001ea4e13c12e36ad6, enter the following command:

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

   Note

   Configure the BIOS of each node to boot from the root disk that you choose. Configure the boot order to boot from the network first, then from the root disk.

Procedure

1. To configure director to use the overcloud-minimal image, create an environment file that contains the following image definition:

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. Replace <roleName> with the name of the role and append Image to the name of the role. The following example shows an overcloud-minimal image for Ceph storage nodes:

   parameter_defaults:
     CephStorageImage: overcloud-minimal

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

   rhsm_enforce: False

4. Pass the environment file to the openstack overcloud deploy command.

Procedure

1. Create a node-info.yaml file in the /home/stack/templates/ directory:

   (undercloud) $ touch /home/stack/templates/node-info.yaml

2. Edit the file to include the node counts and flavors that you need. This example contains 3 Controller nodes and 3 Compute nodes:

   parameter_defaults:
     OvercloudControllerFlavor: control
     OvercloudComputeFlavor: compute
     ControllerCount: 3
     ComputeCount: 3

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-----

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. Source the stackrc file.

   $ source ~/stackrc

2. This validation requires a copy of your overcloud plan. Upload your overcloud plan with all necessary environment files. To upload your plan only, run the openstack overcloud deploy command with the --update-plan-only option:

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

3. Run the openstack tripleo validator run command with the --group pre-deployment option:

   $ openstack tripleo validator run --group pre-deployment

4. If the overcloud uses a plan name that is different to the default overcloud name, set the plan name with the --plan option:

   $ openstack tripleo validator run --group pre-deployment \
       --plan myovercloud

5. Review the results of the validation report. To view detailed output from a specific validation, run the openstack tripleo validator show run --full command against the UUID of the specific validation from the report:

   $ openstack tripleo validator show run --full <UUID>

Procedure

1. Source the stackrc file.

   $ source ~/stackrc

2. Run the openstack tripleo validator run command with the --group post-deployment option:

   $ openstack tripleo validator run --group post-deployment

3. If the overcloud uses a plan name that is different to the default overcloud name, set the plan name with the --plan option:

   $ openstack tripleo validator run --group post-deployment \
       --plan myovercloud

4. Review the results of the validation report. To view detailed output from a specific validation, run the openstack tripleo validator show run --full command against the UUID of the specific validation from the report:

   $ openstack tripleo validator show run --full <UUID>

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": [{
   			"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"
   				}
   			}],
   			"name": "node01",
   			"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"
   		},
   		{
   			"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"
   				}
   			}],
   			"name": "node02",
   			"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:
     - 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
       name: "node01"
       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"
     - 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
       name: "node02"
       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.

   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 Chapter 30, 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.

   pm_port (Optional)

   The port to access the specific IPMI device.

   address

   (Optional) A list of MAC addresses for the network interfaces on the node. Use only the MAC address for the Provisioning NIC of each system.

   physical_network

   (Optional) The physical network that is connected to the Provisioning NIC.

   local_link_connection

   (Optional) 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.

   Important

   When building a multi-architecture cloud, the arch key is mandatory to distinguish nodes using x86_64 and ppc64le architectures.

2. After you create the template, run the following commands to verify the formatting and syntax:

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

   Important

   You must also include the --http-boot /var/lib/ironic/tftpboot/ option for multi-architecture nodes.

3. Save the file to the home directory of the stack user (/home/stack/nodes.json), then run the following commands to import the template to director:

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

   This command registers each node from the template into director. If you use UEFI boot mode, you must also set the boot mode on each node. If you introspect your nodes without setting UEFI boot mode, the nodes boot in legacy mode. For more information, see Setting the boot mode to UEFI boot mode.

4. 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 a new ~/overcloud-baremetal-deploy.yaml 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, use the following syntax:

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

3. In the ~/overcloud-baremetal-deploy.yaml file, define any predictive node placements, custom images, custom NICs, or other attributes that you want to assign to your nodes. For example, use the following example syntax 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

   By default, the provisioning process uses the overcloud-full image. You can use the image attribute in the instances parameter to define a custom image:

   - name: Controller
     count: 3
     instances:
     - hostname: overcloud-controller-0
       name: node00
       image:
         href: overcloud-custom

   You can also override the default parameter values with the defaults parameter to avoid manual node definitions for each node entry:

   - name: Controller
     count: 3
     defaults:
       image:
         href: overcloud-custom
     instances:
     - hostname :overcloud-controller-0
       name: node00
     - hostname: overcloud-controller-1
       name: node01
     - hostname: overcloud-controller-2
       name: node02

   For more information about the parameters, attributes, and values that you can use in your node definition file, see Bare metal node provisioning attributes.

4. Run the provisioning command, specifying the ~/overcloud-baremetal-deploy.yaml file and defining an output file with the --output option:

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

   The provisioning process generates a heat environment file with the name that you specify in the --output option. This file contains your node definitions. When you deploy the overcloud, include this file in the deployment command.

5. In a separate terminal, monitor your nodes to verify that they provision successfully. The provisioning process changes the node state from available to active:

   (undercloud)$ watch openstack baremetal node list

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

   (undercloud)$ metalsmith list

   You can also use the openstack baremetal allocation command to verify association of nodes to hostnames:

   (undercloud)$ openstack baremetal allocation list

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Edit the ~/overcloud-baremetal-deploy.yaml file that you used to provision your bare metal nodes, and increment the count parameter for the roles that you want to scale up. For example, if your overcloud contains three Compute nodes, use the following snippet to increase the Compute node count to 10:

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

   You can also add predictive node placement with the instances parameter. For more information about the parameters and attributes that are available, see Bare metal node provisioning attributes.

3. Run the provisioning command, specifying the ~/overcloud-baremetal-deploy.yaml file and defining an output file with the --output option:

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

4. Monitor the provisioning progress with the openstack baremetal node list command.

5. Deploy the overcloud, including the ~/overcloud-baremetal-deployed.yaml file that the provisioning command generates, along with any other environment files relevant to your deployment:

   (undercloud)$ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Edit the ~/overcloud-baremetal-deploy.yaml file that you used to provision your bare metal nodes, and decrement the count parameter for the roles that you want to scale down. You must also define the following attributes for each node that you want to remove from the stack:

   • The name of the node.
   • The hostname that is associated with the node.

   • The attribute provisioned: false.

     For example, to remove the node overcloud-controller-1 from the stack, include the following snippet in your ~/overcloud-baremetal-deploy.yaml file:

     - name: Controller
       count: 2
       instances:
       - hostname: overcloud-controller-0
         name: node00
       - hostname: overcloud-controller-1
         name: node01
         # Removed from cluster due to disk failure
         provisioned: false
       - hostname: overcloud-controller-2
         name: node02

3. Run the provisioning command, specifying the ~/overcloud-baremetal-deploy.yaml file and defining an output file with the --output option:

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

4. Redeploy the overcloud and include the ~/overcloud-baremetal-deployed.yaml file that the provisioning command generates, along with any other environment files relevant to your deployment:

   (undercloud)$ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e ~/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

   After you redeploy the overcloud, the nodes that you define with the provisioned: false attribute are no longer present in the stack. However, these nodes are still running in a provisioned state.

   Note

   If you want to remove a node from the stack temporarily, you can deploy the overcloud with the attribute provisioned: false and then redeploy the overcloud with the attribute provisioned: true to return the node to the stack.

5. Run the openstack overcloud node delete command, including the ~/overcloud-baremetal-deploy.yaml file with the --baremetal-deployment option.

   (undercloud)$ openstack overcloud node delete \
   --stack stack \
   --baremetal-deployment ~/overcloud-baremetal-deploy.yaml

   Note

   Do not include the nodes that you want to remove from the stack as command arguments in the openstack overcloud node delete command.

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:

   [heat-admin@controller-0 ~]$ sudo subscription-manager register

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

   [heat-admin@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:

   [heat-admin@controller-0 ~]$ sudo subscription-manager attach --pool=pool_id

4. Disable all default repositories:

   [heat-admin@controller-0 ~]$ sudo subscription-manager repos --disable=*

5. Enable the required Red Hat Enterprise Linux repositories.

   1. For x86_64 systems, run the following command:

      [heat-admin@controller-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-rpms

   2. For POWER systems, run the following command:

      [heat-admin@controller-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-ppc64le-baseos-rpms --enable=rhel-8-for-ppc64le-appstream-rpms --enable=rhel-8-for-ppc64le-highavailability-rpms --enable=ansible-2.8-for-rhel-8-ppc64le-rpms --enable=openstack-16-for-rhel-8-ppc64le-rpms --enable=fast-datapath-for-rhel-8-ppc64le-rpms

6. Set the container-tools repository module to version 2.0:

   [heat-admin@controller-0 ~]$ sudo dnf module disable -y container-tools:rhel8
   [heat-admin@controller-0 ~]$ sudo dnf module enable -y container-tools:2.0

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

   [heat-admin@cephstorage-0 ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms --enable=openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms

8. Lock each node to Red Hat Enterprise Linux 8.2 before you execute the dnf update:

   [heat-admin@controller-0 ~]$ sudo subscription-manager release --set=8.2

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

   [heat-admin@controller-0 ~]$ sudo dnf update -y
   [heat-admin@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

1. The name of the assignment, which follows the format <node_hostname>-<network> where the <node_hostname> value matches the short host name for the node, and <network> matches the lowercase name of the network. For example: controller-0-ctlplane for controller-0.example.com and compute-0-ctlplane for compute-0.example.com.

2. The IP assignments, which use the following parameter patterns:

   • fixed_ips/ip_address - Defines the fixed IP addresses for the control plane. Use multiple ip_address parameters in a list to define multiple IP addresses.
   • subnets/cidr - Defines the CIDR value for the subnet.

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. Log in to each pre-provisioned node.

2. Create the /etc/os-net-config/mapping.yaml file and include the details of your interface mapping:

   interface_mapping:
     nic1: em1
     nic2: em2

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

1. Prepare the new pre-provisioned nodes according to Section 9.1, “Pre-provisioned node requirements”.
2. Scale up the nodes. For more information, see Chapter 16, 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.

Procedure

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

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Create a new directory for the additional overcloud that you want to deploy:

   (undercloud)$ mkdir ~/overcloud-two

4. Copy the network_data.yaml file from the existing overcloud to the new directory for the additional overcloud:

   (undercloud)$ cp network_data.yaml ~/overcloud-two/network_data.yaml

5. Open the ~/overcloud-two/network_data.yaml file and update name_lower to a unique name for the the additional overcloud network:

   - name: InternalApi
     name_lower: internal_api_cloud_2
     ...

6. Add service_net_map_replace if not already present, and set the value to the default value of the additional overcloud network:

   - name: InternalApi
     name_lower: internal_api_cloud_2
     service_net_map_replace: internal_api

7. Specify the VLAN IDs for each subnet on the additional overcloud:

   - name: InternalApi
     ...
     vip: true
     vlan: 21
     ip_subnet: '172.21.0.0/24'
     allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}]
     ipv6_subnet: 'fd00:fd00:fd00:2001::/64'
     ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2001::10', 'end': 'fd00:fd00:fd00:2001:ffff:ffff:ffff:fffe'}]
     mtu: 1500
   - name: Storage
     ...

8. Specify the IP address of the gateway for the overcloud-two external network:

   - name: External
     ...
     gateway_ip: <ip_address>
     ...

   • Replace <ip_address> with the IP address of the gateway for the overcloud-two external network, for example, 10.0.10.1.
9. Create a network configuration file for the additional overcloud that overrides the default isolated network configuration provided in the /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml file, for example, network_overrides.yaml.

10. Open the ~/overcloud-two/network_overrides.yaml file and add the IP address of the overcloud-two DNS server:

    parameter_defaults:
      ...
      DnsServers:
        - <ip_address>
      ...

    • Replace <ip_address> with the IP address of the overcloud-two DNS server, for example, 10.0.10.2.

11. If your deployment uses predictable IP addresses, then configure the IP addresses for the overcloud-two nodes in a new network IP address mapping file, ips-from-pool-overcloud-two.yaml:

    parameter_defaults:
      ControllerIPs:
      ...
        internal_api_cloud_2:
        - 192.168.1.10
        - 192.168.1.11
        - 192.168.1.12
        ...
        external_cloud_2:
        - 10.0.1.41
        ...

12. Add your overcloud-two environment files to the stack with your other environment files and deploy the additional overcloud:

    (undercloud)$ openstack overcloud deploy --templates \
      --stack overcloud-two \
      -n ~/overcloud-two/network_data.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
      -e ~/overcloud-two/network_overrides.yaml \
      -e [your environment files] \
      ...

    The deployment process creates overcloud-tworc for interacting with and managing overcloud-two.

13. To interact with your additional overcloud, source the overcloud credential file:

    $ source overcloud-tworc

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the deployment status command:

   $ openstack overcloud status

   The output of this command displays the status of the overcloud:

   +-----------+---------------------+---------------------+-------------------+
   | Plan Name |       Created       |       Updated       | Deployment Status |
   +-----------+---------------------+---------------------+-------------------+
   | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
   +-----------+---------------------+---------------------+-------------------+

   If your overcloud uses a different name, use the --plan argument to select an overcloud with a different name:

   $ openstack overcloud status --plan my-deployment

Procedure

1. Source the overcloudrc file:

   $ source ~/overcloudrc

2. Run the openstack flavor create command to create a flavor. Use the following options to specify the hardware requirements for each flavor:

   --disk

   Defines the hard disk space for a virtual machine volume.

   --ram

   Defines the RAM required for a virtual machine.

   --vcpus

   Defines the quantity of virtual CPUs for a virtual machine.

3. The following example creates the default overcloud flavors:

   $ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
   $ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
   $ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
   $ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
   $ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
   $ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

Procedure

1. Source the overcloudrc file:

   $ source ~/overcloudrc

2. Create the default Tenant network:

   (overcloud) $ openstack network create default

3. Create a subnet on the network:

   (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

4. Confirm the created network:

   (overcloud) $ openstack network list
   +-----------------------+-------------+--------------------------------------+
   | id                    | name        | subnets                              |
   +-----------------------+-------------+--------------------------------------+
   | 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
   +-----------------------+-------------+--------------------------------------+

Procedure

1. Source the overcloudrc file:

   $ source ~/overcloudrc

2. Create the public network:

   • Create a flat network for a native VLAN connection:

     (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre

   • Create a vlan network for non-native VLAN connections:

     (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201

     Use the --provider-segment option to define the VLAN that you want to use. In this example, the VLAN is 201.

3. Create a subnet with an allocation pool for floating IP addresses. In this example, the IP range is 10.1.1.51 to 10.1.1.250:

   (overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

   Ensure that this range does not conflict with other IP addresses in your external network.

Procedure

1. Source the overcloudrc file:

   $ source ~/overcloudrc

2. Create the provider network:

   • Create a flat network for a native VLAN connection:

     (overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share

   • Create a vlan network for non-native VLAN connections:

     (overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share

     Use the --provider-segment option to define the VLAN that you want to use. In this example, the VLAN is 201.

   These example commands create a shared network. It is also possible to specify a tenant instead of specifying --share so that only the tenant has access to the new network.

   + If you mark a provider network as external, only the operator may create ports on that network.

3. Add a subnet to the provider network to provide DHCP services:

   (overcloud) $ openstack subnet create provider-subnet --network  provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

4. Create a router so that other networks can route traffic through the provider network:

   (overcloud) $ openstack router create external

5. Set the external gateway for the router to the provider network:

   (overcloud) $ openstack router set --external-gateway provider external

6. Attach other networks to this router. For example, run the following command to attach a subnet subnet1 to the router:

   (overcloud) $ openstack router add subnet external subnet1

   This command adds subnet1 to the routing table and allows traffic from virtual machines using subnet1 to route to the provider network.

Procedure

1. If you run this test from the undercloud, ensure that the undercloud host has access to the Internal API network on the overcloud. For example, add a temporary VLAN on the undercloud host to access the Internal API network (ID: 201) using the 172.16.0.201/24 address:

   $ source ~/stackrc
   (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
   (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

2. Run the integration tests as described in the OpenStack Integration Test Suite Guide.

3. After completing the validation, remove any temporary connections to the overcloud Internal API. In this example, use the following commands to remove the previously created VLAN on the undercloud:

   $ source ~/stackrc
   (undercloud) $ sudo ovs-vsctl del-port vlan201

Procedure

1. Create an environment file called prevent-stack-delete.yaml.

2. Set the HeatApiPolicies parameter:

   parameter_defaults:
     HeatApiPolicies:
       heat-deny-action:
         key: 'actions:action'
         value: 'rule:deny_everybody'
       heat-protect-overcloud:
         key: 'stacks:delete'
         value: 'rule:deny_everybody'

   Important

   The heat-deny-action is a default policy that you must include in your undercloud installation.

3. Add the prevent-stack-delete.yaml environment file to the custom_env_files parameter in the undercloud.conf file:

   custom_env_files = prevent-stack-delete.yaml

4. Run the undercloud installation command to refresh the configuration:

   $ openstack undercloud install

Procedure

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

2. Source the overcloudrc file:

   $ source ~/stackrc

3. Find the name of the node that you want to access:

   (undercloud) $ openstack server list

4. Connect to the node as the heat-admin user and use the short hostname of the node:

   (undercloud) $ ssh heat-admin@overcloud-controller-0.ctlplane

Procedure

1. On the existing OpenStack environment, create a new image by taking a snapshot of a running server and download the image:

   $ openstack server image create instance_name --name image_name
   $ openstack image save image_name --file exported_vm.qcow2

2. Copy the exported image to the undercloud node:

   $ scp exported_vm.qcow2 stack@192.168.0.2:~/.

3. Log in to the undercloud as the stack user.

4. Source the overcloudrc file:

   $ source ~/overcloudrc

5. Upload the exported image into the overcloud:

   (overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare

6. Launch a new instance:

   (overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

Procedure

1. To view a dynamic inventory of nodes, run the tripleo-ansible-inventory command after sourcing stackrc:

   $ source ~/stackrc
   (undercloud) $ tripleo-ansible-inventory --list

   Use the --list option to return details about all hosts. This command outputs the dynamic inventory in a JSON format:

   {"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}

2. To execute Ansible playbooks on your environment, run the ansible command and include the full path of the dynamic inventory tool using the -i option. For example:

   (undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]

   • Replace [HOSTS] with the type of hosts that you want to use to use:

     • controller for all Controller nodes
     • compute for all Compute nodes
     • overcloud for all overcloud child nodes. For example, controller and compute nodes
     • undercloud for the undercloud
     • "*" for all nodes

   • Replace [OTHER OPTIONS] with additional Ansible options.

     • Use the --ssh-extra-args='-o StrictHostKeyChecking=no' option to bypass confirmation on host key checking.
     • Use the -u [USER] option to change the SSH user that executes the Ansible automation. The default SSH user for the overcloud is automatically defined using the ansible_ssh_user parameter in the dynamic inventory. The -u option overrides this parameter.
     • Use the -m [MODULE] option to use a specific Ansible module. The default is command, which executes Linux commands.
     • Use the -a [MODULE_ARGS] option to define arguments for the chosen module.

Procedure

1. Delete an existing overcloud:

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

2. Confirm that the overcloud is no longer present in the output of the openstack stack list command:

   (undercloud) $ openstack stack list

   Deletion takes a few minutes.

3. When the deletion completes, follow the standard steps in the deployment scenarios to recreate your overcloud.

Procedure

1. Use the setfacl command to grant the stack user on the undercloud access to the files in the /var/lib/mistral directory:

   $ sudo setfacl -R -m u:stack:rwx /var/lib/mistral
   $ sudo chmod -R og-rwx /var/lib/mistral/.ssh

   This command retains mistral user access to the directory.

Procedure

1. View the log with the less command within the config-download working directory. The following example uses the overcloud working directory:

   $ less /var/lib/mistral/overcloud/ansible.log

Procedure

1. Change to the config-download working directory for your overcloud. In this example, the working directory is for the overcloud named overcloud:

   $ cd /var/lib/mistral/overcloud

2. Run the git log command to list the commits in your working directory. You can also format the log output to show the date:

   $ git log --format=format:"%h%x09%cd%x09"
   a7e9063 Mon Oct 8 21:17:52 2018 +1000
   dfb9d12 Fri Oct 5 20:23:44 2018 +1000
   d0a910b Wed Oct 3 19:30:16 2018 +1000
   ...

   By default, the most recent commit appears first.

3. Run the git diff command against two commit hashes to see all changes between the deployments:

   $ git diff a7e9063 dfb9d12

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command. Include any environment files that you require for your overcloud:

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

4. Wait until the deployment process completes.

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command with the --stack-only option. Include any environment files you require for your overcloud:

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

4. Wait until the provisioning process completes.

5. Enable SSH access from the undercloud to the overcloud for the tripleo-admin user. The config-download process uses the tripleo-admin user to perform the Ansible-based configuration:

   $ openstack overcloud admin authorize

6. Perform any manual pre-configuration tasks on nodes. If you use Ansible for configuration, use the tripleo-admin user to access the nodes.

7. Run the deployment command with the --config-download-only option. Include any environment files required for your overcloud:

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

8. Wait until the configuration process completes.

Procedure

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

2. Change to the directory of the Ansible playbook:

   $ cd /var/lib/mistral/overcloud/

3. Change the owner of /var/lib/mistral/.ssh directory to the stack user.

   $ sudo chown stack. -R /var/lib/mistral/.ssh/

4. Run the ansible-playbook-command.sh command to run the overcloud configuration:

   $ sudo ./ansible-playbook-command.sh

5. Change the owner of /var/lib/mistral/.ssh directory to the mistral user. This is required to ensure that the ansible-playbook command running inside the mistral_executor container is successful.

   $ sudo chown 42430:42430 -R /var/lib/mistral/.ssh/

6. Run the script again as the mistral user.

   You can pass additional Ansible arguments to this script, which are then passed unchanged to the ansible-playbook command. This means that you can use other Ansible features, such as check mode (--check), limiting hosts (--limit), or overriding variables (-e). For example:

   $ ./ansible-playbook-command.sh --limit Controller

   Warning

   When --limit is used to deploy at scale, only hosts included in the execution are added to the SSH known_hosts file across the nodes. Therefore, some operations, such as live migration, may not work across nodes that are not in the known_hosts file.

7. Wait until the configuration process completes.

Procedure

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

2. Source the stackrc file:

   $ source ~/stackrc

3. Run the deployment command with the --stack-only option. Include any environment files required for your overcloud:

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

4. Wait until the provisioning process completes.

5. Enable SSH access from the undercloud to the overcloud for the tripleo-admin user. The config-download process uses the tripleo-admin user to perform the Ansible-based configuration:

   $ openstack overcloud admin authorize

6. Generate the config-download files:

   $ openstack overcloud config download \
     --name overcloud \
     --config-dir ~/config-download

   • --name is the name of the overcloud that you want to use for the Ansible file export.
   • --config-dir is the location where you want to save the config-download files.

7. Change to the directory that contains your config-download files:

   $ cd ~/config-download

8. Generate a static inventory file:

   $ tripleo-ansible-inventory \
     --stack <overcloud> \
     --ansible_ssh_user heat-admin \
     --static-yaml-inventory inventory.yaml

   • Replace <overcloud> with the name of your overcloud.

9. Use the config-download files and the static inventory file to perform a configuration. To execute the deployment playbook, run the ansible-playbook command:

   $ ansible-playbook \
     -i inventory.yaml \
     -e gather_facts=true \
     -e @global_vars.yaml \
     --private-key ~/.ssh/id_rsa \
     --become \
     ~/config-download/deploy_steps_playbook.yaml

10. Wait until the configuration process completes.

11. To generate an overcloudrc file manually from this configuration, run the following command:

    $ openstack action execution run \
      --save-result \
      --run-sync \
      tripleo.deployment.overcloudrc \
      '{"container":"overcloud"}' \
      | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

12. Manually set the deployment status to success:

    $ openstack workflow execution create tripleo.deployment.v1.set_deployment_status_success '{"plan": "<OVERCLOUD>"}'

    • Replace <OVERCLOUD> with the name of your overcloud.