21.01 (Draft version in progress)

Summary

The 21.01 OpenStack Charms project release includes updates for the charms described on the Charms page. As of this release, the project consists of 60 supported (stable) charms.

For the list of bugs resolved in this release refer to the 21.01 milestone in Launchpad.

For scheduling information of past and future releases see the Release schedule.

General charm information is published in the OpenStack Charm Guide (this guide) which ultimately supersedes Release Notes contents.

Important

Always upgrade to the latest stable charms before making any major changes to your cloud and before filing bug reports. Refer to section Upgrading charms below for details.

New charm features

With each new feature, there is a corresponding example bundle in the form of a test bundle, and/or a section in the OpenStack Charms Deployment Guide, that details its usage. Test bundles are located in the src/tests/bundles directory of the relevant charm repository.

New charms

Preview charm features

n/a

Deprecation notices

Removed features

Removed charms

n/a

Known issues

Barbican DB migration

With Focal Ussuri, running command barbican-manage db upgrade against a barbican application that is backed by a MySQL InnoDB Cluster will lead to a failure (see bug LP #1899104). This was discovered while resolving bug LP #1827690.

Both the charm bug LP #1827690 and the package bug LP #1899104 are known issues that will be addressed shortly after the 20.10 release.

The package bug only affects Focal Ussuri and is not present in Victoria, nor is it present when using (Bionic) Percona Cluster as the back-end DB.

Designate and Vault at Ocata and earlier

The designate charm for OpenStack Ocata (and earlier) does not yet support SSL via Vault and the certificates relation. See bug LP #1839019. The charm works as intended in this scenario starting with OpenStack Pike.

TrilioVault Data Mover charm upgrade

For deployments using prior versions of the trilio-data-mover charm (as provided by Trilio) the relation between the trilio-data-mover charm and rabbitmq-server must be removed and re-added to ensure that specific access for the data-mover service is provided for RabbitMQ.

juju remove-relation trilio-data-mover rabbitmq-server
juju add-relation trilio-data-mover rabbitmq-server

TrilioVault File Recovery Manager

Mounting snapshots using the File Recovery Manager appliance fails due to permissions errors encountered during the libvirt/qemu snapshot mount process on compute nodes. See bug LP #1888389 for details.

Octavia and neutron-openvswitch in LXD

Note

This issue is due to a Juju bug, which was fixed in Juju 2.8.1.

The octavia charm requires a neutron-openvswitch subordinate which means that if it runs in a container, the openvswitch kernel module must be loaded before the container starts. Module loading is done by LXD based on the profile applied by Juju and taken from the neutron-openvswitch charm. However, due to bug LP #1876849 in Juju, there is no guarantee that the profile will be applied before neutron-openvswitch execution starts in a container.

The issue is more likely to happen on disaggregated deployments where octavia units run in LXD containers on machines that do not have any units of neutron-openvswitch running on bare metal.

In order to work around the error an operator needs to make sure the openswitch module is loaded on the host and then restart the openvswitch-switch.service service inside the LXD container where the respective neutron-openvswitch unit is present. After that the unit error can be resolved.

OpenStack os-brick, Ceph Octopus, and Focal

The Ceph RBD Mirror and Cinder Backup Swift Proxy charms do not work with Ceph Octopus due to an issue with the upstream OpenStack os-brick library (see bug LP #1865754). As Octopus is the default Ceph version on Ubuntu 20.04 LTS (Focal) these charms cannot be used on Focal until the issue is resolved. Here are the resulting charm-specific behaviours:

  • ceph-rbd-mirror charm: The charm will enter a blocked state after configuring pool mirroring (see bug LP #1879749).

  • cinder-backup-swift-proxy charm: If a backup volume operation is performed the resulting volume will be in error (see bug LP #1890821).

Series upgrade - percona-cluster and vault charms

percona-cluster

During a series upgrade from Xenial (16.04) to Bionic (18.04) the percona-cluster charm may fail during the post-series-upgrade hook. This appears to be because the percona-cluster charm may erroneously delete the file /var/lib/percona-xtradb-cluster/seeded (see bug LP #1868326). If this occurs, then executing the following commands on the failed unit will recover the hook and allow it to complete the series upgrade:

juju run percona-cluster/N 'echo "done" > /var/lib/percona-xtradb-cluster/seeded'
juju resolved percona-cluster/N

This may be required for each percona-cluster unit.

vault

If a series upgrade is attempted while Vault is sealed then manual intervention will be required (see bugs LP #1886083 and LP #1890106). The vault leader unit (which will be in error) will need to be unsealed and the hook error resolved. The Vault section in the OpenStack Charms Deployment Guide has detailed unsealing instructions and the hook error can be resolved with:

juju resolved vault/N

Upgrading charms

Always use the latest stable charm revision before proceeding with topological changes, application migrations, workload upgrades, series upgrades, or bug report filing.

Please ensure that the keystone charm is upgraded first.

To upgrade an existing deployment to the latest charm version simply use the upgrade-charm command. For example:

juju upgrade-charm keystone

Charm upgrades and OpenStack upgrades are functionally different. Charm upgrades ensure that the deployment has the latest charm revision, containing the latest charm fixes and features, whereas OpenStack upgrades influence the software package versions of OpenStack itself.

A charm upgrade does not trigger an OpenStack upgrade. An OpenStack upgrade is a separate process. However, an OpenStack upgrade does require the latest charm revision. Please refer to OpenStack upgrades in the OpenStack Charms Deployment Guide for more details.