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
346 lines
13 KiB
ReStructuredText
346 lines
13 KiB
ReStructuredText
.. _release_notes_20.10:
|
|
|
|
=====
|
|
20.10
|
|
=====
|
|
|
|
Summary
|
|
-------
|
|
|
|
The 20.10 OpenStack Charms project release includes updates for the charms
|
|
described on the :doc:`charm guide <../project/openstack-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 `20.10 milestone`_
|
|
in Launchpad.
|
|
|
|
For scheduling information of past and future releases see the
|
|
:doc:`../project/release-schedule`.
|
|
|
|
General 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.
|
|
|
|
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 ``src/tests/bundles``
|
|
directory of the relevant charm repository.
|
|
|
|
OpenStack Victoria
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
The charms now support OpenStack Victoria on Ubuntu 20.10 (natively) and Ubuntu
|
|
20.04 LTS (via UCA).
|
|
|
|
Gnocchi and external root CA for S3
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The gnocchi charm now supports an additional configuration option:
|
|
``trusted-external-ca-cert``. This option installs and configures an external
|
|
root CA in the gnocchi units. This is useful when an encrypted S3 (storage
|
|
backend) endpoint uses certificates that are not managed by Vault.
|
|
|
|
Arista - Supported releases
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The neutron-api-plugin-arista charm now supports all OpenStack releases
|
|
starting with Queens. See bug `LP #1890628`_ for more details.
|
|
|
|
Neutron Gateway and additional data on ports and bridges
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The neutron-gateway charm now marks the openvswitch ports and bridges it
|
|
creates as managed by the charm. It does so by setting an ``external-id`` on
|
|
them. See the `Open vSwitch Integration Guide for Centralized Control`_ for
|
|
details.
|
|
|
|
Even the ports and bridges created before upgrading to this release will be
|
|
marked. Marking our ports and bridges will allow us to implement some cleanup
|
|
mechanism without risking removing too much.
|
|
|
|
See bug `LP #1809190`_ for details.
|
|
|
|
cinder charm: Allow specifying the default_volume type
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
A new feature has been added to allow setting the default volume type, via the
|
|
new configuration parameter ``default-volume-type``, for new volumes if one is
|
|
not specified at creation time. This is to support scenarios where multiple
|
|
storage backends are to be used with cinder. Please see related bug `LP
|
|
#1884548`_ for more details and consult the cinder charm.
|
|
|
|
Action based migration from Neutron ML2+OVS to ML2+OVN
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
New actions have been introduced to enable migration of a Neutron ML2+OVS
|
|
based deployment to ML2+OVN.
|
|
|
|
Please refer to the :doc:`../project/procedures/ovn-migration` page for more
|
|
information.
|
|
|
|
Ceph BlueStore compression support
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Charms that allow for the configuration of Ceph storage can now optionally
|
|
enable Ceph BlueStore compression for the pools they manage. These are:
|
|
|
|
* ceph-fs
|
|
* ceph-radosgw
|
|
* cinder-ceph
|
|
* glance
|
|
* gnocchi
|
|
* nova-compute
|
|
|
|
Configuration options have also been added to the ceph-osd charm which allow
|
|
overriding compression settings for the deployment as a whole.
|
|
|
|
Please refer to individual charm documentation for a description of the
|
|
configuration options.
|
|
|
|
New charms
|
|
----------
|
|
|
|
ceph-iscsi
|
|
~~~~~~~~~~
|
|
|
|
The ceph-iscsi charm is now a supported charm. This charm implements the Ceph
|
|
iSCSI gateway, which provides iSCSI targets backed by a Ceph cluster.
|
|
|
|
Preview charm features
|
|
----------------------
|
|
|
|
n/a
|
|
|
|
Deprecation notices
|
|
-------------------
|
|
|
|
ceph-radosgw charm: Deprecate the pool-prefix config option
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The ``pool-prefix`` configuration option for the ceph-radosgw charm is
|
|
deprecated and will be removed. See bug `LP #1856106`_ for a full discussion.
|
|
|
|
Octavia: Spares pool support is deprecated
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Spares pool support is deprecated upstream, pending removal in the X release.
|
|
The charm will retain support for the feature for OpenStack releases up until
|
|
the X release. Please refer to `Octavia deprecation notes for Victoria`_ for
|
|
more information.
|
|
|
|
Removed features
|
|
----------------
|
|
|
|
Neutron Gateway and network bridges
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The neutron-gateway charm no longer supports adding a Linux bridge to an
|
|
openvswitch bridge. This ability was dependent upon the veth peer links feature
|
|
of NetworkManager (a.k.a. ifupdown). Yet starting with Ubuntu 18.04 LTS
|
|
(Bionic) ifupdown has been replaced by Netplan, which has a feature gap in this
|
|
area (see bug `LP #1876730`_).
|
|
|
|
Using ifupdown on Bionic also causes issues with LXD containers (see bug `LP
|
|
#1877594`_). The latter issue has details on migrating away from veth peer
|
|
links.
|
|
|
|
Removed charms
|
|
--------------
|
|
|
|
n/a
|
|
|
|
Known issues
|
|
------------
|
|
|
|
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`_.
|
|
|
|
Both the charm bug `LP #1827690`_ and the package bug `LP #1899104`_ are known
|
|
issues that will be addressed shortly after the 20.10 release.
|
|
|
|
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.
|
|
|
|
Designate and Vault at Ocata and earlier
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The designate charm for OpenStack Ocata (and earlier) does not yet support SSL
|
|
via Vault and the certificates relation. See bug `LP #1839019`_. The charm
|
|
works as intended in this scenario starting with OpenStack Pike.
|
|
|
|
IP SAN sym links
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
When using the vault certificates relation and vault is configured with
|
|
``auto-generate-root-ca-cert`` set to True (and/or the deprecated setting,
|
|
``totally-unsecure-auto-unlock`` set to true) some charms may be susceptible to
|
|
bug `LP #1893847`_.
|
|
|
|
The symptom is missing sym links to certificates for Subject Alternative Name
|
|
(SAN) IP addresses. For example, for Virtual IP (VIP) addresses for services.
|
|
Apache configuration may fail as it will point to a certificate for the VIP(s).
|
|
|
|
The workaround is to set the above settings to False and utilise the
|
|
post-deployment actions for preparing vault as documented in the `vault
|
|
charm`_.
|
|
|
|
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.
|
|
|
|
.. code-block:: none
|
|
|
|
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`_).
|
|
|
|
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:
|
|
|
|
.. code-block:: none
|
|
|
|
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:
|
|
|
|
.. code-block:: none
|
|
|
|
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
|
|
:command:`upgrade-charm` command. For example:
|
|
|
|
.. code-block:: none
|
|
|
|
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.
|
|
|
|
.. LINKS
|
|
.. _20.10 milestone: https://launchpad.net/openstack-charms/+milestone/20.10
|
|
.. _OpenStack Charms Deployment Guide: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest
|
|
.. _OpenStack Charm Guide: https://docs.openstack.org/charm-guide/latest/
|
|
.. _OpenStack upgrades: https://docs.openstack.org/charm-guide/latest/admin/upgrades/openstack.html
|
|
.. _Open vSwitch Integration Guide for Centralized Control: https://docs.openvswitch.org/en/latest/topics/integration/
|
|
.. _vault charm: https://charmhub.io/vault
|
|
.. _Octavia deprecation notes for Victoria: https://docs.openstack.org/releasenotes/octavia/victoria.html#deprecation-notes
|
|
|
|
.. COMMITS
|
|
|
|
.. BUGS
|
|
.. _LP #1809190: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1809190
|
|
.. _LP #1839019: https://bugs.launchpad.net/charm-designate/+bug/1839019
|
|
.. _LP #1876849: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1876849
|
|
.. _LP #1877594: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1877594
|
|
.. _LP #1876730: https://bugs.launchpad.net/netplan/+bug/1876730
|
|
.. _LP #1890628: https://bugs.launchpad.net/charm-neutron-api-plugin-arista/+bug/1890628
|
|
.. _LP #1868326: https://bugs.launchpad.net/charm-percona-cluster/+bug/1868326
|
|
.. _LP #1890106: https://bugs.launchpad.net/vault-charm/+bug/1890106
|
|
.. _LP #1886083: https://bugs.launchpad.net/vault-charm/+bug/1886083
|
|
.. _LP #1888389: https://bugs.launchpad.net/charm-trilio-data-mover/+bug/1888389
|
|
.. _LP #1865754: https://bugs.launchpad.net/tripleo/+bug/1865754
|
|
.. _LP #1890821: https://bugs.launchpad.net/charm-cinder-backup-swift-proxy/+bug/1890821
|
|
.. _LP #1879749: https://bugs.launchpad.net/charm-ceph-rbd-mirror/+bug/1879749
|
|
.. _LP #1884548: https://bugs.launchpad.net/charm-cinder/+bug/1884548
|
|
.. _LP #1856106: https://bugs.launchpad.net/charm-ceph-radosgw/+bug/1856106
|
|
.. _LP #1827690: https://bugs.launchpad.net/charm-barbican/+bug/1827690
|
|
.. _LP #1899104: https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1899104
|
|
.. _LP #1893847: https://bugs.launchpad.net/charm-helpers/+bug/1893847
|
|
.. _LP #1906280: https://bugs.launchpad.net/charm-ovn-chassis/+bug/1906280
|