Upgrades

To get new features, fix bugs and have a newer OpenStack version, we need to upgrade.

Most of this is copied from Updates. For more information have a look there.

OpenStack upgrades

To support multiple versions of OpenStack all OpenStack services have a .spec.targetRelease field. In this field you can specify the release of this OpenStack service you would like to use (e.g. zed).

In order to upgrade to a new OpenStack release ensure that your service has rolled out successfully (so that it is in the Updated state). Also you need to rollout an operator release supporting the new OpenStack versions. Afterwards you can change the .spec.targetRelease of your service. If the service is capable of non-disruptive upgrades this method will be used. Otherwise the upgrade process might cause disruptions.

Note

You can only upgrade a single version at a time. Jumping over releases is not supported.

The upgrade is finished once the service is again in the Updated state.

If at any point you want to view the OpenStack version currently rolled out at the service you can check .status.installedRelease. This field will always point to the last release that has completed a full rollout. So during normal operation it will be the same as .spec.targetRelease. During upgrades it will show the version you are upgrading from.

For documentation on how the upgrade procedure is implemented please view Openstack Upgrades.