Skip to main content

Upgrades

Upgrade managers before movers because managers assign jobs and manage the database schema. Each deployment method enforces this order:

DeploymentHow the order is kept
kolla-ansiblekolla-ansible upgrade with the service's playbook replaces the managers one at a time, and waits for each to answer before the next. Then it replaces the movers one at a time, including those on manager hosts. Then it replaces all compute agents together. On a host in two groups, each step touches only its own component.
HelmEach mover pod and each compute agent waits until every manager runs its release or a newer one before starting (compute.awaitManagers, on by default).
JujuUnits restart in order when the charms are refreshed.

Backups continue during an upgrade. After a mover restarts, its job resumes using the data already uploaded.

Before you upgrade​

  1. Read the release notes. They list the database migrations a release carries, separately from its other changes.
  2. Back up the service's database. Managers apply migrations at startup. These migrations are not reversed automatically. A release that carries a migration cannot be rolled back by changing the version alone. To go back, restore the database backup and run the previous version.
  3. Pull the images first on kolla-ansible (kolla-ansible pull). deploy and upgrade start whatever image is present. If you change the version without a pull, the old release keeps running and nothing reports it.

After you upgrade​

  • Check that GET /readyz on each manager reports the new version.
  • Check mover availability in System health and versions through GET /v1/movers.
  • Confirm that plans retain their next scheduled runs.
  • Review manager logs for new errors.

Upgrading kolla-ansible itself​

The role and playbook are linked into kolla-ansible's installation directory, which pip replaces on a kolla-ansible upgrade. Run install.sh from the service's deploy/kolla directory again afterwards.