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.
Each operator needs to define the releases it supports in a
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
It maps the release name to a inner
For an example you can check the keystone operator.