21.04 (Draft version in progress)

Summary

The 21.04 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.04 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.

ceph-osd charm: marking individual OSDs as ‘out’ or ‘in’

The ceph-osd charm actions osd-out and osd-in can now target individual OSD volumes. The previous behaviour was to act on all volumes - there is a new keyword ‘all’ for that use case. For example:

juju run-action --wait ceph-osd/0 osd-out osds=osd.0,osd.1
juju run-action --wait ceph-osd/1 osd-out osds=all

Trilio charms

The Trilio charms will no longer be released with the same cadence as the other OpenStack charms. Instead, they will be released shortly after releases of the Trilio code. For instance, Trilio 4.1 is due in February and the Trilio charms will be released shortly thereafter.

New charms

n/a

Preview charm features

Deprecation notices

Removed features

RabbitMQ Ceph relation

The ceph relation in the rabbitmq-server charm is deprecated and will be removed in the 21.04 charm release. The relation exists to support an obsolete method of RabbitMQ clustering which involved sharing queue data between the units using RBD volumes.

Removed charms

n/a

Known issues

Lack of FQDN for containers on physical MAAS nodes may affect running services

When Juju deploys to a LXD container on a physical MAAS node, the container is not informed of its FQDN. The services running in the container will therefore be unable to determine the FQDN on initial deploy and on reboot.

Adverse effects are service dependent. This issue is tracked in bug LP #1896630 in an OVN and Octavia context. Several workarounds are documented in the bug.

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.

Series upgrade - vault charm

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 charm README has unsealing instructions, and the hook error can be resolved with:

juju resolved vault/N

Octavia load balancers using OVN provider on Victoria

With OpenStack Victoria, creating an Octavia load balancer that uses the OVN provider will fail due to bug LP #1896603. This bug does not affect load balancers that use the Amphora provider.

Ceph iSCSI on Ubuntu 20.10

The ceph-iscsi charm can’t be deployed on Ubuntu 20.10 (Groovy) due to a Python library issue. See bug LP #1904199 for details.

Charm upgrade - rabbitmq-server charm

A timing issue has been observed during the upgrade of the rabbitmq-server charm (see bug LP #1912638 for tracking). If it occurs the resulting hook error can be resolved with:

juju resolved rabbitmq-server/N

Adding Glance storage backends

When a storage backend is added to Glance a service restart may be necessary in order for the new backend to be registered. This issue is tracked in bug LP #1914819.

OVS to OVN migration procedure on Ubuntu 20.10

When performed on Ubuntu 20.10 (Groovy), the procedure for migrating an OpenStack cloud from ML2+OVS to ML2+OVN may require an extra step due to Open vSwitch bug LP #1852221.

Following the procedure in the Migration from Neutron ML2+OVS to ML2+OVN section of the deploy guide, the workaround is to restart the ovs-vswitchd service after resuming the ovn-chassis charm in step 15:

juju run-action --wait neutron-openvswitch/0 cleanup
juju run-action --wait ovn-chassis/0 resume
juju run --unit ovn-chassis/0 'systemctl restart ovs-vswitchd'

Documentation updates

Upgrading charms

Upgrading charms will making available new features and bug fixes. However, the latest stable charm revision should also be used prior to making any topological changes, application migrations, workload upgrades, or series upgrades. Bug reports should also be filed against the most recent revision.

Note that charm upgrades and OpenStack upgrades are functionally different. For instructions on performing the different upgrade types see Upgrades overview in the OpenStack Charms Deployment Guide.