Various issues¶
This page documents various issues (software limitations/bugs) that may apply to a Charmed OpenStack cloud. These are still-valid issues that have arisen during the development cycles of past OpenStack Charms releases. The most recently discovered issues are documented in the Release Notes of the latest version of the OpenStack Charms.
The items on this page are distinct from those found on the following pages:
the dedicated Upgrade issues page
the Special charm procedures page
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.
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.
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.
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'