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.
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
directory of the relevant charm repository.
Cinder-Ceph - Image mirroring¶
The cinder-ceph charm now supports image replication to a second Ceph cluster.
This is achieved by connecting its new relation
the second Ceph cluster and setting its new
configuration option to ‘image’.
Whether a particular Cinder Ceph image is replicated or not is determined by its Cinder volume type.
For implementation details see the Cinder-Ceph replication development notes.
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.
Preview charm features¶
Three new tech-preview charms are now available for the deployment of OpenStack Ironic:
Ironic provisions bare metal, as opposed to virtual, machines.
The ‘trusty’ series is no longer actively tested and is now EOL in terms of bug fixes for the OpenStack charms.
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.
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
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'
A summary of documentation updates is given below.
OpenStack Charms Deployment Guide (aka “deploy guide”):
The deploy guide has been completely refactored.
The install section has been updated to OpenStack Victoria.
The upgrades section has received an Upgrades overview page.
OpenStack Charm Guide (aka “charm guide”):
Charm READMEs: cinder, glance, keystone, keystone-ldap, and vault.
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.