Chapter 8. Configuring the overcloud for a Leapp upgrade

The long-life Red Hat OpenStack Platform (RHOSP) upgrade requires a base operating system upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 7 uses the Leapp utility to perform the upgrade to Red Hat Enterprise Linux 8. For more information about Leapp and its dependencies, see Preparing a RHEL 7 system for the upgrade.

The overcloud upgrade framework automatically runs the leapp upgrade. To ensure a successful RHOSP upgrade, it is recommended that you manually run a pre-upgrade report to identify and resolve any potential problems. Run pre-upgrade reports for at least one host of each of the Compute, Controller, and Ceph Storage roles. For more information about Leapp pre-upgrade reports, see Reviewing the pre-upgrade report.

8.1. Creating an upgrades environment file

The upgrade process uses an environment file to enable the upgrade process and configure specific upgrade parameters.

Procedure

  1. Log in to the undercloud as the stack user.
  2. Create an environment file called upgrades-environment.yaml in your templates directory:

    $ touch templates/upgrades-environment.yaml
  3. Edit the file and add the following mandatory content:

    parameter_defaults:
      UpgradeLeappDevelSkip: "LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_TARGET_RELEASE=8.2"
      LeappInitCommand: |
        for module in pata_acpi floppy; do sudo sed -i "/^${module}$/d" /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt; done
        sudo rm -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/persistentnetnamesdisable/actor.py
    • UpgradeLeappDevelSkip skips Leapp checks and sets environment variables when Leapp runs.
    • LeappInitCommand passes commands or script snippets that run on each of the overcloud nodes, and prepares the nodes for the Leapp upgrade.
  4. Save the upgrades-environment.yaml file.

8.2. Upgrade parameters

ParameterDescription

LeappInitCommand

Command or script snippet that runs on all overcloud nodes to prepare the node for the Leapp upgrade process.

UpgradeInitCommand

Command or script snippet to run on all overcloud nodes to initialize the upgrade process. For example, a repository switch.

UpgradeInitCommonCommand

Common commands required by the upgrades process. This should not normally be modified by the operator and is set and unset in the major-upgrade-composable-steps.yaml and major-upgrade-converge.yaml environment files.

UpgradeLeappCommandOptions

Additional command line options to append to the Leapp command.

UpgradeLeappDebug

Print debugging output when running Leapp. The default value is True.

UpgradeLeappDevelSkip

Skip Leapp checks by setting env variables when running Leapp in development/testing. For example, LEAPP_DEVEL_SKIP_RHSM=1.

UpgradeLeappEnabled

Use Leapp for operating system upgrade. The default value is False.

UpgradeLeappPostRebootDelay

Maximum (seconds) to wait for machine to reboot and respond to a test command. The default value is 120.

UpgradeLeappRebootTimeout

Timeout (seconds) for the OS upgrade phase via Leapp. The default value is 3600.

UpgradeLeappToInstall

List of packages to install after Leapp upgrade.

UpgradeLeappToRemove

List of packages to remove during Leapp upgrade.

8.3. Copying the Leapp data on the overcloud nodes

Each overcloud node requires Leapp data files. Copy the data files in the /etc/leapp/files directory on the undercloud to the same location on each overcloud node.

Procedure

  1. Log in to the undercloud as the stack user.
  2. Source the stackrc file.

    $ source ~/stackrc
  3. Create a static inventory file of all the nodes in your environment:

    $ tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack STACK_NAME

    If you are not using the default overcloud stack name, set your stack name with the --stack STACK NAME option replacing STACK NAME with the name of your stack.

  4. To copy the leapp data to the overcloud nodes, run the following synchronize Ansible command:

    $ ansible -i ~/inventory.yaml --become -m synchronize -a "src=/etc/leapp/files dest=/etc/leapp/" overcloud

8.4. Using predictable NIC names for overcloud nodes

Before you run the Leapp upgrade on overcloud nodes, you must check for kernel-based NIC names, which usually contain an eth prefix. These NIC names are usually unpredictable in terms of NIC assignments.

You can run the playbook-nics.yaml playbook to rename NIC names to use the em NIC prefix. You can also set a different NIC prefix, by modifying the prefix variable when running the playbook. However, the NIC changes are only applied after the Leapp upgrade process completes and the node is rebooted.

Prerequisites

  • The playbook-nics.yaml playbook created during the undercloud preparation process. The playbook-nics.yaml playbook accommodates most overcloud networking scenarios that use Ethernet devices, bridges, and Linux bonds. If your environment requires additional configuration beyond these device types, follow these recommendations before proceeding:

    • Test the playbook on a separate system with a similar networking configuration to your overcloud nodes
    • Modify the playbook to accommodate renaming the eth prefix within the configuration of other device types
    • Check the networking configuration of your overcloud nodes after you complete this procedure

Procedure

  1. Log in to the undercloud as the stack user.
  2. Run the playbook-nics.yaml playbook on all overcloud nodes:

    $ ansible-playbook -i ~/inventory.yaml playbook-nics.yaml

    The playbook sets the new NIC prefix to em. To set a different NIC prefix, set the prefix variable when running the playbook:

    $ ansible-playbook -i ~/inventory.yaml -e prefix="mynic" playbook-nics.yaml

    The NIC changes are only applied after the Leapp upgrade process completes and the node is rebooted.

8.5. Setting the SSH root permission parameter on the overcloud

The Leapp upgrade checks whether the PermitRootLogin parameter exists in the /etc/ssh/sshd_config file on each node. You must explicitly set this parameter to either yes or no.

For security purposes, set this parameter to no to disable SSH access to the root user on overcloud nodes.

Prerequisites

  • An Ansible inventory file for your overcloud nodes.

Procedure

  1. Log in to the undercloud as the stack user.
  2. Create a file called playbook-ssh.yaml and paste the following content in the file:

    ---
    - name: Configure SSH PermitRootLogin parameter
      hosts: overcloud
      become: yes
      tasks:
        - name: Set the PermitRootLogin parameter to no
          lineinfile:
            path: /etc/ssh/sshd_config
            state: present
            line: "PermitRootLogin no"
  3. Run the playbook:

    $ ansible-playbook -i ~/inventory.yaml playbook-ssh.yaml