The 20.02 OpenStack Charms 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.
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.
The policy overrides feature provides operators with a mechanism to override policy defaults on a per-service basis.
Policy defaults for an OpenStack service are defined via “policy-in-code” and/or via a default policy YAML file provided by the charm. The operator can use the new feature by providing a ZIP file consisting of at least one YAML file which contains policy rules that the service will observe when responding to API queries. This allows operators to selectively override the default policies of that service.
The last release (19.10) introduced the feature for a number of charms. This release adds the following charms:
Please consult the README for each charm to determine exactly what is provided with respect to this feature.
The vault charm now supports actions
resume to respectively
stop and start the Vault process on units.
Disabling snapshots as a boot source for the OpenStack dashboard¶
Snapshots can be disabled as valid boot sources for launching instances in the
dashboard. This is done via the new
option in the openstack-dashboard charm. If ‘true’ then snapshots will not
show up in the Launch Instance modal dialog box.
This option works from the Newton release, and has no effect on earlier OpenStack releases.
CephFS, Manila, and Manila-Ganesha¶
The 20.02 OpenStack Charms release includes a new charm to support Ganesha for use with Manila and CephFS. Manila and CephFS are also moving to supported status.
The manila-ganesha charm only supports OpenStack releases starting at Rocky. Manila and CephFS are both supported back to Mitaka (on Ubuntu 16.04 LTS).
Preview charm features¶
mysql-innodb-cluster and mysql-router¶
The 20.02 OpenStack Charms release updates two tech preview charms to deploy MySQL 8 for OpenStack: mysql-innodb-cluster and mysql-router. Both are available for use with Ubuntu 19.10 (Eoan).
These two charms will replace the percona-cluster charm completely in the 20.05 Charms release.
The MySQL 8 charms are in preview state and are ready for testing. They are not production-ready.
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 mysql-router 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 cs:keystone juju deploy cs:~openstack-charmers-next/mysql-router keystone-mysql-router juju deploy -n 3 cs:~openstack-charmers-next/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
In Ubuntu 20.04 LTS (Focal) percona-cluster will no longer be available. The migration process is currently under development in the charms to ease the number of required steps. Here is a high level overview:
Deploy mysql-innodb-cluster alongside an existing deployment
Remove the relation between the application charm and the percona-cluster charm
Dump the existing database from percona-cluster
Import the database into mysql-innodb-cluster
Deploy and relate an instantiation of mysql-router to the client charm i.e. <application-name>-mysql-router
Relate <application-name>-mysql-router to mysql-innodb-cluster
Charmed OpenStack clouds upgrading their nodes to Ubuntu 20.04 LTS will need to migrate from the percona-cluster charm to both the mysql-router and mysql-innodb-cluster charms.
The 20.02 OpenStack Charms release updates the tech preview suite of charms that allows you to model Open Virtual Network (OVN). OVN provides open source network virtualization for Open vSwitch (OVS).
Swift Global Replication¶
As of the 20.02 charm release, with OpenStack Newton or later, support for a global cluster in Swift is available as a tech preview. Please see Multi-region cluster in the OpenStack Charms Deployment Guide for more information on enabling the feature.
If a fork of the Swift charms is in use which has this feature enabled then a charm upgrade will almost certainly cause issues. This is due to changes in charm config options and the way the Swift init scripts are configured.
The watcher charm deploys the OpenStack Watcher service, the resource optimisation service for multi-tenant clouds. The watcher-dashboard charm provides a dashboard plugin for use with the OpenStack dashboard (Horizon). As of the 20.02 OpenStack Charms release these charms are available as a tech preview.
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.
New bundle features¶
Upcoming change of default behaviour for Neutron API¶
The neutron-api charm will have a change in default behaviour when deploying
OpenStack Ussuri (or newer) with the upcoming 20.05 OpenStack Charms release
(May 2020). The value of configuration option
manage-neutron-plugin-legacy-mode will change from ‘True’ to ‘False’.
When ‘True’ the network management plugin is chosen via the
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 change will be made within the following upstream context:
During the Ussuri cycle the upstream Neutron project will switch to promote ML2+OVN as its 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. Documentation on migrating existing clouds to OVN will be provided.
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
configuration option allows the operator to control which Swift operator roles
will be authenticated, as usual. See the Swift Auth System for further
Masakari and Masakari Monitors¶
Both Masakari charms remain as previews. Bugs LP #1728527 and LP #1839715 need to be resolved in order to arrive at a successful instance HA deployment. Bug LP #1773765 is likely to affect on-going support of a Masakari deployment.
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"
The 20.02 OpenStack Charms release includes 53 bug fixes. Refer to the 20.02 milestone in Launchpad for the list of resolved bugs.
Next release info¶
Please see the OpenStack Charm Guide for current information.