Upgrade OpenStack¶
This section provides instructions on how to upgrade the OpenStack version on a MOSK cluster.
Prerequisites¶
Verify that your OpenStack cloud is running on the latest MOSK release. See Release Compatibility Matrix for the release matrix and supported upgrade paths.
Just before the upgrade, back up your OpenStack databases. See the following documentation for details:
Verify that OpenStack is healthy and operational. All OpenStack components in the
health
group in theOpenStackDeploymentStatus
CR should be in theReady
state. See OpenStackDeploymentStatus custom resource for details.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.
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.
Calculate the maintenance window using Services update details and notify users.
When upgrading to OpenStack Yoga, remove the Panko service from the cloud by removing the
event
entry from thespec:features:services
structure in theOpenStackDeployment
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, andSTATE
displaysAPPLYING
: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 displayAPPLIED
:kubectl -n openstack get osdplst NAME OPENSTACK VERSION CONTROLLER VERSION STATE osh-dev victoria 0.5.8.dev15 APPLIED
Verify the upgrade¶
Verify that OpenStack is healthy and operational. All OpenStack components in the
health
group in theOpenStackDeploymentStatus
CR should be in theReady
state. See OpenStackDeploymentStatus custom resource for details.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:
Upgrade the cloud from
victoria
towallaby
Upgrade the cloud from
wallaby
toxena
Upgrade the cloud from
xena
toyoga
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.