openstack/charm-guide
Code Issues Proposed changes
Files
master
charm-guide/doc/source/release-notes/2008.rst
Peter Matulis 45fb20b14e Remove CDG redirects 
This is a doc maintenance task.

Use local links instead of using the redirects that
are configured in the Deploy Guide (due to pages that
were migrated to this current guide). This includes links
implemented via the intersphinx plugin (i.e. cdg:****)

Change-Id: Ieb2607c4cd89a241c377da1808286b80b06bb93e
2022-09-28 16:40:40 -04:00

20 KiB
Raw Permalink Blame History

20.08

Summary

The 20.08 OpenStack Charms project release includes updates for the charms described in the following sections. Refer to the 20.08 milestone in Launchpad for the list of resolved bugs and see the ../project/release-schedule for past and future releases.

Additional 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.

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.

Charm cinder-ceph now requires 'ceph-access' relation to charm nova-compute

When both the nova-compute and cinder-ceph applications are deployed a new relation is now required. In this context, if the 'ceph-access' relation endpoint is not present between cinder-ceph and nova-compute the latter charm will go into the blocked state. This should not affect most currently deployed clouds, but it will affect new deployments. See commit Require relation to nova-compute application for details.

To add the relation:

juju add-relation nova-compute:ceph-access cinder-ceph:ceph-access

Glance Simplestreams Sync

The glance-simplestreams-sync charm now installs simplestreams as a snap. As such it no longer has a source configuration option (the new snap-channel option is used to select a channel in the Snap store).

There is now a Juju action to perform a one-time sync of images: sync-images.

Gnocchi S3 support

The gnocchi charm can now be configured to use S3 as a storage backend. By default it uses Ceph. For more details see the gnocchi charm README.

Note

S3 storage support for Gnocchi is available starting with OpenStack Stein.

Keystone Kerberos support

The new keystone-kerberos subordinate charm can be used to add Kerberos support to Keystone by authenticating to an OpenStack domain. An external Kerberos server is needed. For more details see the keystone-kerberos charm README.

Note

Keystone Kerberos is supported starting with OpenStack Queens.

MySQL InnoDB Cluster TLS communication

TLS communication between MySQL InnoDB Cluster and its cloud clients is now supported. Previously, TLS was only enabled for inter-MySQL client communication by way of a self-signed certificate.

Due to the circular dependency between the vault and mysql-innodb-cluster applications, the enablement of this feature can only be done post-deployment (once vault has been initialised and has a root Certificate Authority).

Database TLS communication is enabled with this relation:

juju add-relation mysql-innodb-cluster:certificates vault:certificates

New charms

Arista

The neutron-api-plugin-arista charm is now an officially supported charm.

Note

For now the neutron-api-plugin-arista charm is only supported up to OpenStack Queens. The ongoing work for supporting other releases is tracked in LP #1890628.

This subordinate charm provides the Arista ML2 Plugin support to the OpenStack Neutron API service.

When this charm is related to the neutron-api charm it will install the Arista Neutron packages on each neutron-api unit in the region and supply the desired configuration to the neutron-api service.

For more details see the neutron-api-plugin-arista charm README.

For upgrading from earlier prototypes see Upgrading to stable Arista charm.

Trilio charms

The trilio-data-mover, trilio-dm-api, trilio-horizon-plugin, and trilio-wlm charms are now officially supported. These charms deploy TrilioVault, a commercial snapshot and restore solution for OpenStack. For details see the TrilioVault Data Protection section of the OpenStack Charms Deployment Guide.

Note

The Trilio charms are currently only supported on Ubuntu 18.04 LTS (Bionic).

Preview charm features

Deprecation notices

ceph-osd charm autotune option

The autotune configuration option for the ceph-osd charm is deprecated and will be removed in the 20.10 release of OpenStack Charms. See bug LP #1798794 for a full discussion.

glance-simplestreams-sync charm use_swift option

The use_swift configuration option for the glance-simplestreams-sync charm is deprecated and will be removed in the 20.10 release of OpenStack Charms.

This option allowed simplestreams metadata to be hosted on an Apache server local to a glance-simplestreams-sync unit. Object storage will become the only way to store this metadata.

Removed features

Glance Simplestreams Sync

The glance-simplestreams-sync charm no longer supports deployment with the rabbitmq-server charm. Bundles which specify this relation will need to be updated.

To prevent possible race conditions during the deployment of a cloud, the behaviour of enabling synchronisation via Cron by default has changed. You will now need to manually enable this feature (via the run configuration option):

juju config glance-simplestreams-sync run=true

Known issues

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 File Recovery Manager

Mounting snapshots using the File Recovery Manager appliance fails due to permissions errors encountered during the libvirt/qemu snapshot mount process on compute nodes. See bug LP #1888389 for details.

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.

OpenStack os-brick, Ceph Octopus, and Focal

The Ceph RBD Mirror and Cinder Backup Swift Proxy charms do not work with Ceph Octopus due to an issue with the upstream OpenStack os-brick library (see bug LP #1865754). As Octopus is the default Ceph version on Ubuntu 20.04 LTS (Focal) these charms cannot be used on Focal until the issue is resolved. Here are the resulting charm-specific behaviours:

  • ceph-rbd-mirror charm: The charm will enter a blocked state after configuring pool mirroring (see bug LP #1879749).
  • cinder-backup-swift-proxy charm: If a backup volume operation is performed the resulting volume will be in error (see bug LP #1890821).

Rabbitmq Scale-Out

The 20.08 OpenStack Charms release contains a fix to bug LP #1796886 which is a bug relating to scaling-out rabbitmq-server. Please upgrade the rabbitmq-server charm and all charms with an amqp relation before scaling-out rabbitmq-server.

Series upgrade - percona-cluster and vault charms

percona-cluster

During a series upgrade from Xenial (16.04) to Bionic (18.04) the percona-cluster charm may fail during the post-series-upgrade hook. This appears to be because the percona-cluster charm may erroneously delete the file /var/lib/percona-xtradb-cluster/seeded (see bug LP #1868326). If this occurs, then executing the following commands on the failed unit will recover the hook and allow it to complete the series upgrade:

juju run percona-cluster/N 'echo "done" > /var/lib/percona-xtradb-cluster/seeded'
juju resolved percona-cluster/N

This may be required for each percona-cluster unit.

vault

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

juju resolved vault/N

Upgrading charms

Always use the latest stable charm revision before proceeding with topological changes, application migrations, workload upgrades, series upgrades, or bug report filing.

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.

View Git Blame Copy Permalink