Openstack upgrades are implemented as part of the normal operator statemachine. Using special guard resources, individual resources 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 resources¶
The following two methods can be used as
condition= parameter for
yaook.statemachine.OptionalKubernetesReference as a wrapper guard for the wrapped resources 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 resources 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.