operating-kolla.rst

Operating Kolla

Versioning

Kolla uses the x.y.z semver nomenclature for naming versions. Kolla's initial Pike release was 5.0.0 and the initial Queens release is 6.0.0. The Kolla community commits to release z-stream updates every 45 days that resolve defects in the stable version in use and publish those images to the Docker Hub registry.

To prevent confusion, the Kolla community recommends using an alpha identifier x.y.z.a where a represents any customization done on the part of the operator. For example, if an operator intends to modify one of the Docker files or the repos from the originals and build custom images for the Pike version, the operator should start with version 5.0.0.0 and increase alpha for each release. Alpha tag usage is at discretion of the operator. The alpha identifier could be a number as recommended or a string of the operator's choosing.

To customize the version number uncomment openstack_release in globals.yml and specify the version number desired. If openstack_release is not specified, Kolla will deploy or upgrade using the version number information contained in the kolla-ansible package.

Upgrade procedure

Note

If you have set enable_cells to yes then you should read the upgrade notes in the :ref:`Nova cells guide<nova-cells-upgrade>`.

Kolla's strategy for upgrades is to never make a mess and to follow consistent patterns during deployment such that upgrades from one environment to the next are simple to automate.

Kolla implements a one command operation for upgrading an existing deployment consisting of a set of containers and configuration data to a new deployment.

Limitations and Recommendations

Note

Varying degrees of success have been reported with upgrading the libvirt container with a running virtual machine in it. The libvirt upgrade still needs a bit more validation, but the Kolla community feels confident this mechanism can be used with the correct Docker storage driver.

Note

Because of system technical limitations, upgrade of a libvirt container when using software emulation (virt_type = qemu in nova.conf), does not work at all. This is acceptable because KVM is the recommended virtualization driver to use with Nova.

Note

Please note that when the use_preconfigured_databases flag is set to "yes", you need to have the log_bin_trust_function_creators set to 1 by your database administrator before performing the upgrade.

Ubuntu Focal 20.04

The Victoria release adds support for Ubuntu Focal 20.04 as a host operating system. Ubuntu users upgrading from Ussuri should first upgrade OpenStack containers to Victoria, which uses the Ubuntu Focal 20.04 base container image. Hosts should then be upgraded to Ubuntu Focal 20.04.

CentOS Stream 8

The Wallaby release adds support for CentOS Stream 8 as a host operating system. CentOS Stream 8 support will also be added to a Victoria stable release. CentOS Linux users upgrading from Victoria should first migrate hosts and container images from CentOS Linux to CentOS Stream before upgrading to Wallaby.

Preparation

While there may be some cases where it is possible to upgrade by skipping this step (i.e. by upgrading only the openstack_release version) - generally, when looking at a more comprehensive upgrade, the kolla-ansible package itself should be upgraded first. This will include reviewing some of the configuration and inventory files. On the operator/master node, a backup of the /etc/kolla directory may be desirable.

If upgrading from 5.0.0 to 6.0.0, upgrade the kolla-ansible package:

pip install --upgrade kolla-ansible==6.0.0

If this is a minor upgrade, and you do not wish to upgrade kolla-ansible itself, you may skip this step.

The inventory file for the deployment should be updated, as the newer sample inventory files may have updated layout or other relevant changes. Use the newer 6.0.0 one as a starting template, and merge your existing inventory layout into a copy of the one from here:

/usr/share/kolla-ansible/ansible/inventory/