Openstack Upgrades

Openstack upgrades are implemented as part of the normal operator statemachine. Using special guard states, individual states can be configured to be skipped during upgrades or to be only executed during upgrades.

The reason for this implementation way is that we assume for now that most parts of the statemachine are actually the same across versions and during upgrades. In case an upgrade procedure or a new openstack version has a completely different way of working this idea might not make sense.

Release definitions

Each operator needs to define the releases it supports in a RELEASES array. It contains the supported releases in an ordered way. This ordering is also used to determine if a given targetRelease is a valid upgrade target.

Upgrade guard states

The following two states can be used as a wrapper guard the wrapped states in case of upgrades.


Only executes when currently an upgrade is in progress. This will probably be mostly use for database migration jobs


Only executes when no upgrade is in progress. This is probably used for the initial db sync

To ensure appropriate ordering of running e.g. db migration jobs you will need to mark the above metioned states as dependencies on appropriate places. E.g. the db-premigration should be a dependency of the service api. This will ensure that only after the premigration actually finishes the api pods are updated.

Docker image versions

In order to use different docker images based on the release of the service you can use a ReleaseAwareVersionedDependency. It maps the release name to a inner VersionedDependency.

For an example you can check the keystone operator.