20.05¶
Summary¶
The 20.05 OpenStack Charms project release includes updates for the following charms. Additional charm support status information is published in the OpenStack Charm Guide which ultimately supersedes Release Notes contents.
Always use the latest stable charm revision before proceeding with topological changes, application migrations, workload upgrades, series upgrades, or bug reports.
OpenStack charms (Stable)¶
These charms have stable releases with ongoing maintenance and testing. They meet the requirements of payload project health, payload packaging, upgradability, charm test gates, and the general release guidelines of the OpenStack Charms project.
Other supporting charms (Stable)¶
These charms have stable releases with ongoing maintenance and testing. They are classified differently because the payload of each is not technically an OpenStack project.
Tech-preview charms (Beta)¶
These charms do not have stable releases, even though they may technically have “stable/yy.mm” branches. Regardless of any maintenance and testing that these charms may receive, some work (major bugs, payload packaging issues, project issues, general QA) is still required before the charms are ready for production use (promoted to Stable).
Alpha charms (Edge)¶
This classification of charms includes those which may be a proof-of-concept, a test fixture, or one which is in active development. They are not intended to be used in production. Supportability, upgradability, testability may be lacking, either from a charm perspective, or from the workload package perspective.
Maintenance-mode charms¶
These charms are in maintenance mode, meaning that new features and new releases are not actively being added or tested with them. Generally, these were produced for a demo, PoC, or as an example.
None at this time.
Removed charms¶
n/a
New charm features¶
With each new feature, there is a corresponding example bundle in the form of a
test bundle, and/or a OpenStack Charms Deployment Guide section which
details the use of the feature. For example test bundles, see the
src/tests/bundles directory within the relevant charm repository.
OpenStack Ussuri¶
The charms now support OpenStack Ussuri on Ubuntu 18.04 LTS (via UCA) and Ubuntu 20.04 LTS natively. See below note OpenStack Ussuri packages for Ubuntu 20.04 LTS.
Ceph Octopus¶
On OpenStack Ussuri, the Octopus release of Ceph is now supported.
Configuring security compliance for Keystone¶
Keystone has several configuration options available in order to comply with standards such as the Payment Card Industry – Data Security Standard (PCI-DSS) v3.1. The keystone charm can now set these options.
The password-security-compliance charm option sets Keystone service options
for the [security_compliance] section of Keystone’s configuration file.
Note
Please ensure that the page Security compliance and PCI-DSS is consulted
before setting these options. The charm does set the
ignore_change_password_upon_first_use and ignore_password_expiry
options to ‘true’ for the service accounts to prevent lockout of service
users.
Please consult the Keystone charm README for more details on the option.
Cinder charm support for Juju storage¶
The cinder charm has now grown support for Juju storage. Please see Juju storage and the Cinder charm README for more details.
Enable counting of quota usage from Placement service¶
The upstream configuration parameter ‘count_usage_from_placement’ introduced in OpenStack Train is now supported. This boolean parameter enables the counting of quota usage from the placement service instead of from the cell databases.
The parameter is set via quota-count-usage-from-placement option in the
nova-cloud-controller charm. The default value of this option is ‘False’.
Note
Please ensure to consult the page Nova Train configuration options in the OpenStack documentation before setting the charm option.
OVS hardware offload with Mellanox ConnectX-5¶
The Neutron charms (neutron-api and neutron-openvswitch) now support hardware offload of network connectivity for instances via Open vSwitch with Mellanox ConnectX-5 (or later) network cards.
Details on how to deploy Neutron with this feature can be found in the NIC hardware offload appendix in the OpenStack Charms Deployment Guide.
Networking tools for charms¶
As a result of refactoring the charm codebase responsible for configuration of SR-IOV VF functions and to support the new OVS hardware offload features for Mellanox network cards the neutron-openvswitch charm now makes use of two networking tools (sriov-netplan-shim and mlnx-switchdev-mode) provided via the Networking Tools PPA.
This PPA can be mirrored for offline deployments - the neutron-openvswitch charm may be configured to use a mirror for these packages using the ‘networking-tools-source’ configuration option.
Change of default behaviour for Neutron API¶
The neutron-api charm has a change in default behaviour when deploying
OpenStack Ussuri (or newer). The value of configuration option
manage-neutron-plugin-legacy-mode has changed from ‘True’ to ‘False’.
When ‘True’ the network management plugin is chosen via the neutron-plugin
configuration option. When ‘False’ plugin is chosen through the deployment of a
subordinate charm and relating it to the neutron-api application.
The most prominent effect of the change is that you will need to set up a subordinate plugin charm (and possibly associated charms) to get a functional network service. Sample bundles will be updated to enable OVN by default. See Open Virtual Network (OVN) in the OpenStack Charms Deployment Guide for details on OVN.
This is made within the following upstream context:
During the Ussuri cycle the upstream Neutron project has promoted the ML2+OVN to an in-tree driver and moving forward it will be the default reference implementation, replacing the traditional ML2+OVS and ML2+OVS+DVR implementations. See the Toward Convergence of ML2+OVS+DVR and OVN Neutron specification for more information.
The desire for a more sensible default mode of operation enabling easier integration with the rich plugin ecosystem available for OpenStack Neutron.
Upgrading neutron-api or upgrading OpenStack will not trigger the new behaviour.
New charms¶
MySQL 8 charms¶
Two new supported charms to deploy MySQL 8 for OpenStack are introduced: mysql-innodb-cluster and mysql-router. These charms will replace the percona-cluster charm completely for Ubuntu 20.04 LTS (Focal) and newer deployments.
The mysql-innodb-cluster charm deploys MySQL 8 in an InnoDB cluster with a read/write node and N number of read-only nodes. This charm does not support single-unit or non-clustered deployments.
The mysql-router charm deploys a MySQL 8 Router which will proxy database requests from the principle charm application to a MySQL 8 InnoDB cluster. MySQL Router handles cluster communication and understands the cluster schema. The charm is deployed as a subordinate on the principle charm application and should be named accordingly at deploy time (e.g. <application-name>-mysql-router).
A simple example deployment:
juju deploy keystone
juju deploy mysql-router keystone-mysql-router
juju deploy -n 3 mysql-innodb-cluster
juju add-relation keystone-mysql-router:shared-db keystone:shared-db
juju add-relation keystone-mysql-router:db-router mysql-innodb-cluster:db-router
A more complex example bundle is available in OpenStack bundles Focal Ussuri.
In Ubuntu 20.04 LTS (Focal) percona-cluster will no longer be available. The migration process is documented in the Specific series upgrade procedures page in the OpenStack Charms Deployment Guide.
Masakari charms¶
The masakari, masakari-monitors, and pacemaker-remote charms are now supported charms. From Stein onwards the charms can be used to provide instance failover in the event of hypervisor failure. From Ussuri onwards the charms can restart an instance if it fails. The charms do not support using Masakari to manage processes on the hypervisor. Details on how to deploy the Masakari charms can be found in the Automated instance recovery appendix in the OpenStack Charms Deployment Guide.
Bug LP #1773765 is likely to affect on-going support of a Masakari deployment.
OVN charms¶
Four new supported charms to deploy OVN are introduced: neutron-api-plugin-ovn, ovn-central, ovn-chassis and ovn-dedicated-chassis. These charms provide the underlying networking facilities for, and integrate with, OpenStack Neutron through the OVN ML2 driver.
Key differences from the legacy ML2+OVS solution:
All forwarding is programmed into Open vSwitch using OpenFlow rules (Layer2 switching, Layer3 routing, Security group rules, DHCP, DNS). This allows for less agents and namespaces on hypervisors, and may also allow for Layer 3 routing to be offloaded to NICs with appropriate driver and firmware support.
Warning
Support for hardware offload in conjunction with OVN as provided by the charms is an experimental feature. OVN uses different tunnel protocols and programs flow tables in a different way than legacy ML2+OVS and this has had less exposure to our validation of NIC firmware and driver support.
Distributed East/West traffic by default, highly available North/South routing by default.
More flexible configuration of external Layer3 connectivity, dedicated gateway nodes and wiring external connectivity to every hypervisor is not required.
OVN is the preferred default for new deployments of OpenStack Ussuri on Ubuntu 18.04 LTS (Bionic) and 20.04 LTS (Focal). Please refer to the Open Virtual Network (OVN) appendix in the OpenStack Charms Deployment Guide for more details on deploying OpenStack with OVN. A complete example bundle is available in OpenStack bundles Focal Ussuri.
Note
There are feature gaps from ML2+OVS and deploying legacy ML2+OVS with the OpenStack Charms is still available if you require any of the missing features.
Documentation on, and actions for, migrating existing clouds to OVN will be delivered as part of the 20.10 OpenStack Charms release.
Preview charm features¶
TrilioVault support¶
New charms are provided for the deployment of TrilioVault, which provides an OpenStack integrated snapshot and restore service for workloads. Note that this set of preview charms are targeted only to the Bionic (Ubuntu 18.04 LTS) series at this time.
For more details see the TrilioVault appendix in the OpenStack Charms Deployment Guide.
Note
TrilioVault is a commercial snapshot and restore solution for OpenStack and does not form part of the OpenStack project.
ceph-iscsi¶
The new preview ceph-iscsi charm can be used to deploy Ceph iSCSI gateways. These gateways provide iSCSI targets backed by a Ceph cluster. The charm requires Focal (Ubuntu 20.04 LTS) and cannot be deployed in a LXD container. It can, however, co-exist with the ceph-osd charm. For more details see the Ceph iSCSI Gateway README.
Upgrading charms¶
Always use the latest stable charm revision before proceeding with topological changes, charm application migrations, workload upgrades, series upgrades, or bug reports.
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.
Deprecation notices¶
Neutron Firewall-as-a-Service (FWaaS)¶
Due to lack of maintainers the Neutron FWaaS project has been deprecated in the Neutron stadium and will be removed in the W cycle. Subsequently the charm support for FWaaS is deprecated for Ussuri and onwards.
Charm support for FWaaS will be retained for enabled OpenStack releases and configuration options will have no effect when deployed with the W release and onwards.
Note
A side effect of the FWaaS deprecation is that no new development has occurred upstream in a while. Subsequently there exists no support for FWaaS for use with OVN. Depending on your requirements instance security groups may be used instead.
Removed features¶
Keystone support for admin-token¶
The admin-token configuration option has been removed from the keystone
charm. The use of the Keystone admin token feature is not recommended and is at
odds with the Identity service Security Checklist.
Note
There was no deprecation warning for removal of this configuration option as its removal was required to fix a long standing Keystone charm bug. See LP #1859844 for details.
Known issues¶
OpenStack Ussuri packages for Ubuntu 20.04 LTS¶
Due to the slightly-offset release dates of OpenStack Ussuri and Ubuntu 20.04 LTS, the final upstream stable release of Ussuri is undergoing a stable release update (SRU) into Ubuntu 20.04 LTS as of the release date of these charms.
Testing and validation for this OpenStack Charms release has taken place using
the packages that are currently in distro-proposed. The status of the SRU
process is tracked in the following bugs:
It is possible to consume the proposed packages by using ‘distro-proposed’ as
the value for the openstack-origin and source charm configuration
options.
Swift-Proxy and Policy.d overrides¶
The is no policy.d override mechanism available for Swift (and, therefore, the
swift-proxy charm) as Swift does not use the oslo.policy library. Swift
uses its own authentication system that connects with Keystone and validates
according to Swift’s own configuration files. The operator-roles
configuration option allows the operator to control which Swift operator roles
will be authenticated, as usual. See the Swift Auth System for further
details.
Glance Simplestreams Sync¶
When deploying the glance-simplestreams-sync charm on Bionic a more recent version of the simplestreams package must be installed by configuring a PPA:
juju config glance-simplestreams-sync source=ppa:simplestreams-dev/trunk
See bug LP #1790904 for details.
Designate and Vault at Ocata and earlier¶
The designate charm for OpenStack releases Pike and earlier does not yet support SSL via Vault and the certificates relation. See bug LP #1839019.
Current versions of OpenStack with Vault and the certificates relation are supported by the Designate charm.
Restart Nova services after adding certificates relation¶
A race condition exists with the use of the ‘certificates’ relation. When SSL certificates are issued Nova services may attempt to talk to the placement API over HTTP while the API has already changed to HTTPS. See bug LP #1826382.
To mitigate against this, restart the nova-compute and nova-scheduler services once certificates have been issued:
juju run --application nova-compute "systemctl restart nova-compute"
juju run --application nova-cloud-controller "systemctl restart nova-scheduler"
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 package upgrades¶
Changing the value of the ‘triliovault-pkg-source’ option does not currently trigger a package upgrade although the apt sources for the unit are updated.
Packages can be manually upgraded after changing this option - for example:
juju run --application trilio-dm-api "sudo apt -y dist-upgrade"
See bug LP #1879904 for more details.
Designate upgrades to Train¶
When upgrading Designate to OpenStack Train, there is an encoding issue between the designate-producer and memcached that causes the designate-producer to crash. See bug LP #1828534. This can be resolved by restarting the memcached service.
juju run --application=memcached 'sudo systemctl restart memcached'
Octavia and neutron-openvswitch in LXD¶
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 a combination of bugs (LP #1876849 in Juju and LP #1906280 in the ovn-chassis/neutron-openvswitch charms) there is no guarantee that the profile will be applied before neutron-openvswitch (or ovn-chassis) 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.
Ceph RBD Mirror and Ceph Octopus¶
Due to an unresolved permission issue the ceph-rbd-mirror charm will stay in a blocked state after configuring mirroring for pools when connected to a Ceph Octopus cluster. See bug LP #1879749 for details.
Minimum Juju version for deploying Octavia¶
Juju 2.7 and above should be used for deployments with the octavia charm since
it has dependencies that require the LANG environment variable to be set
during package installation. Juju versions prior to 2.7 do not set the LANG
variable in hook executions which leads to the default python decoder being set
to ASCII - this results in decoding issues when one of the dependent package’s
setup.py script gets executed and reads a source file containing UTF-8 code
units. As a result, the following error can be seen in a hook error:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc8 in position 129: ordinal not in range(128)
See bug LP #1879184 for more information.
This issue affects existing Juju 2.6 environments as well if a charm upgrade is performed. It will be addressed by fixing GH #173.
Bugs fixed¶
The 20.05 OpenStack Charms release includes 89 bug fixes. Refer to the 20.05 milestone in Launchpad for the list of resolved bugs.
Next release info¶
Please see the OpenStack Charm Guide for current information.
