Openstack Upgrades

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.

For documentation on how to upgrade OpenStack at your yaook cluster, see Upgrades.

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 resources

The following two methods can be used as condition= parameter for yaook.statemachine.Optional and yaook.statemachine.OptionalKubernetesReference as a wrapper guard for the wrapped resources in case of upgrades.

yaook.statemachine.optional_only_upgrade

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

yaook.statemachine.optional_non_upgrade

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 ReleaseAwareVersionedDependency. It maps the release name to a inner VersionedDependency.

For an example you can check the keystone operator.