Chapter 6. Executing Post Upgrade Steps

This process implements final steps after completing the main upgrade process.

Prerequisites

  • You have completed the overcloud upgrade to the latest major release.

6.1. Including the Undercloud CA on New Overcloud Nodes

In Section 4.8, “Preparing Access to the Undercloud’s Public API over SSL/TLS” we added the undercloud certificate authority (CA) on all existing overcloud nodes. New nodes added to the environment, either through scaling or replacement, also require the CA so that the new overcloud node has access to the OpenStack Object Storage (swift) Public API. This procedure shows how to include the undercloud CA on all new overcloud nodes.

Prerequisites

  • You have upgraded to Red Hat OpenStack Platform 12.
  • Your undercloud uses SSL/TLS for its Public API.

Procedure

  1. Create a new or edit an existing environment file. This example uses the filename undercloud-ca-map.yaml.

  2. Add the CAMap parameter to the parameter_defaults section of the environment file. Use the following syntax as an example: 

    parameter_defaults:
  CAMap:
    undercloud-ca: 1
      content: | 2
        -----BEGIN CERTIFICATE-----
        MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3D
        BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZ
        UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5M
        ...
        ...
        -----END CERTIFICATE-----
    1
    This is the name that identifies the CA in each overcloud node’s trust database.
    2
    The content section is the actual CA certificate. Copy and paste the CA content in this section. Ensure the CA’s indentation matches the requirements for YAML syntax.
  3. Save this file.
  4. Include this file with subsequent execution of the openstack overcloud deploy command.

Related Information

6.2. General Considerations after an Overcloud Upgrade

The following items are general considerations after an overcloud upgrade:

  • If necessary, review the resulting configuration files on the overcloud nodes. The upgraded packages might have installed .rpmnew files appropriate to the upgraded version of each service.

  • The Compute nodes might report a failure with neutron-openvswitch-agent. If this occurs, log into each Compute node and restart the service. For example: 

    $ sudo systemctl restart neutron-openvswitch-agent

  • In some circumstances, the corosync service might fail to start on IPv6 environments after rebooting Controller nodes. This is due to Corosync starting before the Controller node configures the static IPv6 addresses. In these situations, restart Corosync manually on the Controller nodes: 

    $ sudo systemctl restart corosync