Procedure

1. Log into the undercloud as the root user.

2. Create a backup directory, and change the user ownership of the directory to the stack user:

   [root@director ~]# mkdir /backup
   [root@director ~]# chown stack: /backup

3. From the backup directory, back up the database:

   [root@director ~]# cd /backup
   [root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

4. Archive the database backup and the configuration files:

   [root@director ~]# tar --xattrs --ignore-failed-read -cf \
       undercloud-backup-`date +%F`.tar \
       /root/undercloud-all-databases.sql \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /var/lib/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   • The --ignore-failed-read option skips any directory that does not apply to your undercloud.
   • The --xattrs option includes extended attributed, which are required to store metadata for Object Storage (swift).

   This creates a file named undercloud-backup-<date>.tar.gz, where <date> is the system date. Copy this tar file to a secure location.

Procedure

1. Perform the database backup:

   1. Log into a Controller node. You can access the overcloud from the undercloud:

      $ ssh heat-admin@192.0.2.100

   2. Change to the root user:

      $ sudo -i

   3. Create a temporary directory to store the backups:

      # mkdir -p /var/tmp/mysql_backup/

   4. Obtain the database password and store it in the MYSQLDBPASS environment variable. The password is stored in the mysql::server::root_password variable within the /etc/puppet/hieradata/service_configs.json file. Use the following command to store the password:

      # MYSQLDBPASS=$(sudo hiera mysql::server::root_password)

   5. Backup the database:

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-`date +%F`-`date +%T`.sql

      This dumps a database backup called /var/tmp/mysql_backup/openstack_databases-<date>.sql where <date> is the system date and time. Copy this database dump to a secure location.

   6. Backup all the users and permissions information:

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-`date +%F`-`date +%T`.sql

      This will dump a database backup called /var/tmp/mysql_backup/openstack_databases_grants-<date>.sql where <date> is the system date and time. Copy this database dump to a secure location.

2. Backup the OpenStack Telemetry database:

   1. Connect to any controller and get the IP of the MongoDB primary instance:

      # MONGOIP=$(sudo hiera mongodb::server::bind_ip)

   2. Create the backup:

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. Copy the database dump in /var/tmp/mongo_backup/ to a secure location.

3. Backup the Redis cluster:

   1. Obtain the Redis endpoint from HAProxy:

      # REDISIP=$(sudo hiera redis_vip)

   2. Obtain the master password for the Redis cluster:

      # REDISPASS=$(sudo hiera redis::masterauth)

   3. Check connectivity to the Redis cluster:

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. Dump the Redis database:

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      This stores the database backup in the default /var/lib/redis/ directory. Copy this database dump to a secure location.

4. Backup the filesystem on each Controller node:

   1. Create a directory for the backup:

      # mkdir -p /var/tmp/filesystem_backup/

   2. Run the following tar command:

      # tar --ignore-failed-read --xattrs \
          -zcvf /var/tmp/filesystem_backup/fs_backup-`date '+%Y-%m-%d-%H-%M-%S'`.tar.gz \
          /var/lib/config-data \
          /var/log/containers \
          /etc/corosync \
          /etc/logrotate.d \
          /etc/openvswitch \
          /var/log/openvswitch \
          /srv/node \
          /home/heat-admin

      The --ignore-failed-read option ignores any missing directories, which is useful if certain services are not used or separated on their own custom roles.

5. Copy the resulting tar file to a secure location.

Procedure

1. Log into the director as the stack user.

2. Update the python-tripleoclient package and its dependencies to ensure you have the latest scripts for the minor version update:

   $ sudo yum update -y python-tripleoclient

3. The director uses the openstack undercloud upgrade command to update the Undercloud environment. Run the command:

   $ openstack undercloud upgrade

4. Wait until the undercloud upgrade process completes.

5. Reboot the undercloud to update the operating system’s kernel and other system packages:

   $ sudo reboot

6. Wait until the node boots.

Procedure

1. Find the latest tag for the containerized service images:

   $ openstack overcloud container image tag discover \
     --image registry.access.redhat.com/rhosp12/openstack-base:latest \
     --tag-from-label version-release

   Make a note of the most recent tag.

2. Create an updated environment file for your container image source. Run using the openstack overcloud container image prepare command. For example, to use images from registry.access.redhat.com:

   $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp12 \
     --prefix=openstack- \
     --tag [TAG] \ 1
     --set ceph_namespace=registry.access.redhat.com/rhceph \
     --set ceph_image=rhceph-2-rhel7 \
     --set ceph_tag=latest \
     --env-file=/home/stack/templates/overcloud_images.yaml \
     -e /home/stack/templates/custom_environment_file.yaml 2

   1

   Replace [TAG] with the tag obtained from the previous step.

   2

   Include all additional environment files with the -e parameter. The director checks the custom resources in all included environment files and identifies the container images required for the containerized services.

   For more information about generating this environment file for different source types, see "Configuring a container image source" in the Director Installation and Usage guide.

3. Run the openstack overcloud update stack command to update the container image locations in your overcloud:

   $ openstack overcloud update stack --init-minor-update \
     --container-registry-file /home/stack/templates/overcloud_images.yaml

   The --init-minor-update only performs an update of the parameters in the overcloud stack. It does not perform the actual package or container update. Wait until this command completes.

4. Perform a package and container update using the openstack overcloud update command. Using the --nodes option to upgrade node for each role. For example, the following command updates nodes in the Controller role

   $ openstack overcloud update stack --nodes Controller

   Run this command for each role group in the following order:

   • Controller
   • CephStorage
   • Compute
   • ObjectStorage
   • Any custom roles such as Database, MessageBus, Networker, and so forth.
5. The update process starts for the chosen role starts. The director uses an Ansible playbook to perform the update and displays the output of each task.
6. Update the next role group. Repeat until you have updated all nodes.

Procedure

1. Select a node to reboot. Log into it and stop the cluster before rebooting:

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop

2. Reboot the node:

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

3. Wait until the node boots.

4. Re-enable the cluster for the node:

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start

5. Log into the node and check the services. For example:

   1. If the node uses Pacemaker services, check the node has rejoined the cluster:

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. If the node uses Systemd services, check all services are enabled:

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

Procedure

1. Log into a Ceph MON or Controller node and disable Ceph Storage cluster rebalancing temporarily:

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. Select the first Ceph Storage node to reboot and log into it.

3. Reboot the node:

   $ sudo reboot

4. Wait until the node boots.

5. Log into the node and check the cluster status:

   $ sudo ceph -s

   Check that the pgmap reports all pgs as normal (active+clean).

6. Log out of the node, reboot the next node, and check its status. Repeat this process until you have rebooted all Ceph storage nodes.

7. When complete, log into a Ceph MON or Controller node and enable cluster rebalancing again:

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

8. Perform a final status check to verify the cluster reports HEALTH_OK:

   $ sudo ceph status

Procedure

1. Log into the undercloud as the stack user.

2. List all Compute nodes and their UUIDs:

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

   Identify the UUID of the Compute node you aim to reboot.

3. From the undercloud, select a Compute Node and disable it:

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set [hostname] nova-compute --disable

4. List all instances on the Compute node:

   (overcloud) $ openstack server list --host [hostname] --all-projects

5. Use one of the following commands to migrate your instances:

   1. Migrate the instance to a specific host of your choice:

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   2. Let nova-scheduler automatically select the target host:

      (overcloud) $ nova live-migration [instance-id]

   3. Live migrate all instances at once:

      $ nova host-evacuate-live [hostname]

      Note

      The nova command might cause some deprecation warnings, which are safe to ignore.

6. Wait until migration completes.

7. Confirm the migration was successful:

   (overcloud) $ openstack server list --host [hostname] --all-projects

8. Continue migrating instances until none remain on the chosen Compute Node.

9. Log into the Compute Node and reboot it:

   [heat-admin@overcloud-compute-0 ~]$ sudo reboot

10. Wait until the node boots.

11. Enable the Compute Node again:

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set [hostname] nova-compute --enable

12. Check whether the Compute node is enabled:

    (overcloud) $ openstack compute service list

Procedure

1. Source the undercloud access details:

   $ source ~/stackrc

2. Check for failed Systemd services:

   (undercloud) $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. Check the undercloud free space:

   (undercloud) $ df -h

   Use the "Undercloud Reqirements" as a basis to determine if you have adequate free space.

4. If you have NTP installed on the undercloud, check that clocks are synchronized:

   (undercloud) $ sudo ntpstat

5. Check the undercloud network services:

   (undercloud) $ openstack network agent list

   All agents should be Alive and their state should be UP.

6. Check the undercloud compute services:

   (undercloud) $ openstack compute service list

   All agents' status should be enabled and their state should be up

Procedure

1. Source the undercloud access details:

   $ source ~/stackrc

2. Check the status of your bare metal nodes:

   (undercloud) $ openstack baremetal node list

   All nodes should have a valid power state (on) and maintenance mode should be false.

3. Check for failed Systemd services:

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. Check for failed containerized services:

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

5. Check the HAProxy connection to all services. Obtain the Control Plane VIP address and authentication details for the haproxy.stats service:

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

   Use these details in the following cURL request:

   (undercloud) $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   Replace <PASSWORD> and <IP ADDRESS> details with the respective details from the haproxy.stats service. The resulting list shows the OpenStack Platform services on each node and their connection status.

6. Check overcloud database replication health:

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec clustercheck clustercheck" ; done

7. Check RabbitMQ cluster health:

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

8. Check Pacemaker resource health:

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   Look for:

   • All cluster nodes online.
   • No resources stopped on any cluster nodes.
   • No failed pacemaker actions.

9. Check the disk space on each overcloud node:

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. Check overcloud Ceph Storage cluster health. The following command runs the ceph tool on a Controller node to check the cluster:

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Check Ceph Storage OSD for free space. The following command runs the ceph tool on a Controller node to check the free space:

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

12. Check that clocks are synchronized on overcloud nodes

    (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. Source the overcloud access details:

    (undercloud) $ source ~/overcloudrc

14. Check the overcloud network services:

    (overcloud) $ openstack network agent list

    All agents should be Alive and their state should be UP.

15. Check the overcloud compute services:

    (overcloud) $ openstack compute service list

    All agents' status should be enabled and their state should be up

16. Check the overcloud volume services:

    (overcloud) $ openstack volume service list

    All agents' status should be enabled and their state should be up.

Procedure

1. Log into the director as the stack user.

2. Disable the current OpenStack Platform repository:

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. Enable the new OpenStack Platform repository:

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

4. Run yum to upgrade the director’s main packages:

   $ sudo yum update -y python-tripleoclient

5. Run the following command to upgrade the undercloud:

   $ openstack undercloud upgrade

6. Wait until the undercloud upgrade process completes.

7. Reboot the undercloud to update the operating system’s kernel and other system packages:

   $ sudo reboot

8. Wait until the node boots.

Procedure

1. Remove any existing images from the images directory on the stack user’s home (/home/stack/images):

   $ rm -rf ~/images/*

2. Extract the archives:

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
   $ cd ~

3. Import the latest images into the director:

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

4. Configure your nodes to use the new images:

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

5. Verify the existence of the new images:

   $ openstack image list
   $ ls -l /httpboot

Procedure

1. Install the openstack-tripleo-heat-templates-compat package:

   $ sudo yum install openstack-tripleo-heat-templates-compat

   This installs the previous templates in the compat directory of your Heat template collection (/usr/share/openstack-tripleo-heat-templates/compat) and also creates a link to compat named after the previous version (ocata). These templates are backwards compatible with the upgraded director, which means you can use the latest version of the director to install an overcloud of the previous version.

2. Create a temporary copy of the core Heat templates:

   $ cp -a /usr/share/openstack-tripleo-heat-templates /tmp/osp13

3. Move the previous version into its own directory:

   $ mv /tmp/osp12/compat /tmp/osp12

4. Perform a diff on the contents of both directories:

   $ diff -urN /tmp/osp12 /tmp/osp13

   This shows the core template changes from one version to the next. These changes provide an idea of what should occur during the overcloud upgrade.

Procedure

1. To pull the images directly from registry.access.redhat.com in your overcloud deployment, an environment file is required to specify the image parameters. The following command automatically creates this environment file:

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • Use the -e option to include any environment files for optional services.
   • If using Ceph Storage, include the additional parameters to define the Ceph Storage container image location: --set ceph_namespace, --set ceph_image, --set ceph_tag.
2. This creates an overcloud_images.yaml environment file, which contains image locations, on the undercloud. You include this file with your deployment.

Procedure

1. Find the address of the local undercloud registry. The address will use the following pattern:

   <REGISTRY IP ADDRESS>:8787

   Use the IP address of your undercloud, which you previously set with the local_ip parameter in your undercloud.conf file. For the commands below, the address is assumed to be 192.168.24.1:8787.

2. Create a template to upload the the images to the local registry, and the environment file to refer to those images:

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • Use the -e option to include any environment files for optional services.
   • If using Ceph Storage, include the additional parameters to define the Ceph Storage container image location: --set ceph_namespace, --set ceph_image, --set ceph_tag.

3. This creates two files:

   • local_registry_images.yaml, which contains container image information from the remote source. Use this file to pull the images from the Red Hat Container Registry (registry.access.redhat.com) to the undercloud.

   • overcloud_images.yaml, which contains the eventual image locations on the undercloud. You include this file with your deployment.

     Check that both files exist.

4. Pull the container images from registry.access.redhat.com to the undercloud.

   (undercloud) $ sudo openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   Pulling the required images might take some time depending on the speed of your network and your undercloud disk.

   Note

   The container images consume approximately 10 GB of disk space.

5. The images are now stored on the undercloud’s docker-distribution registry. To view the list of images on the undercloud’s docker-distribution registry using the following command:

   (undercloud) $  curl http://192.0.2.5:8787/v2/_catalog | jq .repositories[]

   To view a list of tags for a specific image, use the skopeo command:

   (undercloud) $ skopeo inspect --tls-verify=false docker://192.0.2.5:8787/rhosp13/openstack-keystone | jq .RepoTags[]

   To verify a tagged image, use the skopeo command:

   (undercloud) $ skopeo inspect --tls-verify=false docker://192.0.2.5:8787/rhosp13/openstack-keystone:13.0-44

Procedure

1. Create a template to pull images to the local registry:

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images \

   • Use the -e option to include any environment files for optional services.
   • If using Ceph Storage, include the additional parameters to define the Ceph Storage container image location: --set ceph_namespace, --set ceph_image, --set ceph_tag.
   Note

   This version of the openstack overcloud container image prepare command targets the registry on the registry.access.redhat.com to generate an image list. It uses different values than the openstack overcloud container image prepare command used in a later step.

2. This creates a file called satellite_images with your container image information. You will use this file to synchronize container images to your Satellite 6 server.

3. Remove the YAML-specific information from the satellite_images file and convert it into a flat file containing only the list of images. The following sed commands accomplish this:

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   This provides a list of images that you pull into the Satellite server.

4. Copy the satellite_images_names 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.

5. Run the following hammer command to create a new product (OSP13 Containers) to your Satellite organization:

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

   This custom product will contain our images.

6. Add the base container image to the product:

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

7. Add the overcloud container images from the satellite_images file.

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

8. Synchronize the container images:

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP13 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. See the "Authentication" section in the Hammer CLI Guide.

9. If your Satellite 6 server uses content views, create a new content view version to incorporate the images.

10. Check the tags available for the base image:

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    This displays tags for the OpenStack Platform container images.

11. Return to the undercloud and generate an environment file for the images on your Satellite server. The following is an example command for generating the environment file:

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    Note

    This version of the openstack overcloud container image prepare command targets the Satellite server. It uses different values than the openstack overcloud container image prepare command used in a previous step.

    When running this command, include the following data:

    • --namespace - The URL and port of the registry on the Satellite server. The default registry port on Red Hat Satellite is 5000. For example, --namespace=satellite6.example.com:5000.

    • --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-myosp13-osp13_containers-.
      • If you do not use content views, the structure is [org]-[product]-. For example: acme-osp13_containers-.
    • --tag-from-label {version}-{release} - Identifies the latest tag for each image.
    • -e - Include any environment files for optional services.

    • --set ceph_namespace, --set ceph_image, --set ceph_tag - If using Ceph Storage, include the 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 --prefix option. For example:

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      This ensures the overcloud uses the Ceph container image using the Satellite naming convention.

12. This creates an overcloud_images.yaml environment file, which contains the image locations on the Satellite server. You include this file with your deployment.

Procedure

1. Edit the environment file containing your registration details. For example:

   $ vi ~/templates/rhel-registration/environment-rhel-registration.yaml

2. Edit the following parameter values:

   rhel_reg_repos

   Update to include the new repositories for Red Hat OpenStack Platform 13.

   rhel_reg_activation_key

   Update the activation key to access the Red Hat OpenStack Platform 13 repositories.

   rhel_reg_sat_repo

   If using a newer version of Red Hat Satellite 6, update the repository containing Satellite 6’s management tools.

3. Save the environment file.

Procedure

1. Select an environment file and the check if it has an ExtraConfig parameter:

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. If the results show an ExtraConfig parameter for any role (e.g. ControllerExtraConfig) in the chosen file, check the full parameter structure in that file.

3. If the parameter contains any puppet Hierdata with a SECTION/parameter syntax followed by a value, it might have been been replaced with a parameter with an actual Puppet class. For example:

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. Check the director’s Puppet modules to see if the parameter now exists within a Puppet class. For example:

   $ grep dnsmasq_local_resolv

   If so, change to the new interface.

5. The following are examples to demonstrate the change in syntax:

   • Example 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     Changes to:

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • Example 2:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     Changes to:

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the upgrade preparation command:

   $ openstack overcloud upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e <ENVIRONMENT FILE>

   Include the following options relevant to your environment:

   • Custom configuration environment files (-e)
   • The environment file with your new container image locations (-e). Note that the upgrade command might display a warning about using the --container-registry-file. You can ignore this warning as this option is deprecated in favor of using -e for the container image environment file.
   • If applicable, your custom roles (roles_data) file using --roles-file.
   • If applicable, your composable network (network_data) file using --networks-file.
3. Wait until the upgrade preparation completes.

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the upgrade command:

   $ openstack overcloud upgrade run --nodes Controller

   • If using a custom stack name, pass the name with the --stack option.
3. Wait until the Controller node upgrade completes.

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the upgrade command:

   $ openstack overcloud upgrade run --nodes Compute

   • If using a custom stack name, pass the name with the --stack option.
3. Wait until the Compute node upgrade completes.

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the upgrade command:

   $ openstack overcloud upgrade run --nodes CephStorage

   • If using a custom stack name, pass the name with the --stack option.
3. Wait until the node upgrade completes.

4. Run the Ceph Storage upgrade command. For example:

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   Include the following options relevant to your environment:

   • Custom configuration environment files (-e). For example:

     • The environment file with your container image locations (overcloud_images.yaml). Note that the upgrade command might display a warning about using the --container-registry-file. You can ignore this warning as this option is deprecated in favor of using -e for the container image environment file.
     • The relevant environment files for your Ceph Storage nodes.
     • Any additional environment files relevant to your environment.
   • If using a custom stack name, pass the name with the --stack option.
   • If applicable, your custom roles (roles_data) file using --roles-file.
   • If applicable, your composable network (network_data) file using --networks-file.
5. Wait until the Ceph Storage node upgrade completes.

Procedure

1. Source the stackrc file:

   $ source ~/stackrc

2. Run the upgrade finalization command:

   $ openstack overcloud upgrade converge \
       --templates \
       -e <ENVIRONMENT FILE>

   Include the following options relevant to your environment:

   • Custom configuration environment files (-e).
   • If using a custom stack name, pass the name with the --stack option.
   • If applicable, your custom roles (roles_data) file using --roles-file.
   • If applicable, your composable network (network_data) file using --networks-file.
3. Wait until the upgrade finalization completes.