Upgrade OpenStack

This section provides instructions on how to upgrade the OpenStack version on a MOSK cluster.

Prerequisites

  1. Verify that your OpenStack cloud is running on the latest MOSK release. See Release Compatibility Matrix for the release matrix and supported upgrade paths.

  2. Just before the upgrade, back up your OpenStack databases. See the following documentation for details:

  3. Verify that OpenStack is healthy and operational. All OpenStack components in the health group in the OpenStackDeploymentStatus CR should be in the Ready state. See OpenStackDeploymentStatus custom resource for details.

  4. Verify the workability of your OpenStack deployment by running Tempest against the OpenStack cluster as described in Run Tempest tests. Verification of the testing pass rate before upgrading will help you measure your cloud quality before and after upgrade.

  5. Read carefully through the Release Notes of your MOSK version paying attention to the Known issues section and the OpenStack upstream release notes for the target OpenStack version.

  6. Calculate the maintenance window using services-update-details and notify users.

  7. When upgrading to OpenStack Yoga, remove the Panko service from the cloud by removing the event entry from the spec:features:services structure in the OpenStackDeployment resource as described in Remove an OpenStack service.

    Note

    The OpenStack Panko service has been removed from the product. See Deprecation Notes: The OpenStack Panko service for details.

Perform the upgrade

To start the OpenStack upgrade, change the value of the spec:openstack_version parameter in the OpenStackDeployment object to the target OpenStack release.

Caution

It is not allowed to do skip level upgrades as well as downgrades.

When you change the value of the spec:openstack_version parameter, the OpenStack Controller initializes the upgrade process.

To verify the upgrade status, use:

  • Logs from the osdpl container in the OpenStack Controller pod.

  • The OpenStackDeploymentStatus object.

    When upgrade starts, the OPENSTACK VERSION field content changes to the target OpenStack version, and STATE displays APPLYING:

    kubectl -n openstack get osdplst
NAME      OPENSTACK VERSION   CONTROLLER VERSION   STATE
osh-dev   victoria            0.5.8.dev15          APPLYING

    When upgrade finishes, the STATE field should display APPLIED:

    kubectl -n openstack get osdplst
NAME      OPENSTACK VERSION   CONTROLLER VERSION   STATE
osh-dev   victoria            0.5.8.dev15          APPLIED

Verify the upgrade

  1. Verify that OpenStack is healthy and operational. All OpenStack components in the health group in the OpenStackDeploymentStatus CR should be in the Ready state. See OpenStackDeploymentStatus custom resource for details.

  2. Verify the workability of your OpenStack deployment by running Tempest against the OpenStack cluster as described in Run Tempest tests.

Upgrade from Victoria to Yoga

Caution

If your cluster is running on top of the MOSK 23.1.2 patch version, the OpenStack upgrade to Yoga may fail due to the delay in the Cinder start. For the workaround, see 23.1.2 known issues: OpenStack upgrade failure.

Before upgrading, verify that you have completed the Prerequisites.

If your cloud runs on top of the OpenStack Victoria release, you must first upgrade to the technical OpenStack releases Wallaby and Xena before upgrading to the Yoga release.

Complete the upgrade steps for each release version in line in the following strict order:

  1. Upgrade the cloud from victoria to wallaby

  2. Upgrade the cloud from wallaby to xena

  3. Upgrade the cloud from xena to yoga

Caution

The Wallaby and Xena releases are not recommended for long-run production usage. These are transitional, so-called technical releases with a limited testing scope. For the OpenStack versions support cycle, refer to OpenStack support cycle.

The maintenance window for OpenStack upgrade from one release to another usually takes from two to four hours, depending on the cloud size. You can calculate the maintenance window using services-update-details.