Browse Source
Add dedicated OpenStack upgrade migration path pages to make it clearer for upgraders. Doing so also removes non-relevant text from the general upgrade-issues page. Add a redirect to account for the deleted placement charm special procedure page. Closes-Bug: #1970272 Change-Id: Ibd09e9e0d66a6f9e152f37c6ac675eed35c97bdechanges/84/843184/6
Peter Matulis
3 months ago
10 changed files with 200 additions and 144 deletions
@ -0,0 +1,23 @@
|
||||
:orphan: |
||||
|
||||
========================= |
||||
Upgrade: Mitaka to Newton |
||||
========================= |
||||
|
||||
This page contains notes specific to the Mitaka to Newton upgrade path. See the |
||||
main :doc:`upgrade-openstack` page for full coverage. |
||||
|
||||
neutron-gateway charm options |
||||
----------------------------- |
||||
|
||||
Between the Mitaka and Newton OpenStack releases, the neutron-gateway charm |
||||
added two options, ``bridge-mappings`` and ``data-port``, which replaced the |
||||
(now) deprecated ``ext-port`` option. This was to provide for more control over |
||||
how ``neutron-gateway`` can configure external networking. Unfortunately, the |
||||
charm was only designed to work with either ``ext-port`` (no longer |
||||
recommended) *or* ``bridge-mappings`` and ``data-port``. |
||||
|
||||
See bug `LP #1809190`_. |
||||
|
||||
.. BUGS |
||||
.. _LP #1809190: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1809190 |
||||
@ -0,0 +1,65 @@
|
||||
:orphan: |
||||
|
||||
======================== |
||||
Upgrade: Newton to Ocata |
||||
======================== |
||||
|
||||
This page contains notes specific to the Newton to Ocata upgrade path. See the |
||||
main :doc:`upgrade-openstack` page for full coverage. |
||||
|
||||
cinder/ceph topology change |
||||
--------------------------- |
||||
|
||||
If cinder is directly related to ceph-mon rather than via cinder-ceph then |
||||
upgrading from Newton to Ocata will result in the loss of some block storage |
||||
functionality, specifically live migration and snapshotting. To remedy this |
||||
situation the deployment should migrate to using the cinder-ceph charm. This |
||||
can be done after the upgrade to Ocata. |
||||
|
||||
.. warning:: |
||||
|
||||
Do not attempt to migrate a deployment with existing volumes to use the |
||||
cinder-ceph charm prior to Ocata. |
||||
|
||||
The intervention is detailed in the below three steps. |
||||
|
||||
Step 0: Check existing configuration |
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
Confirm existing volumes are in an RBD pool called 'cinder': |
||||
|
||||
.. code-block:: none |
||||
|
||||
juju run --unit cinder/0 "rbd --name client.cinder -p cinder ls" |
||||
|
||||
Sample output: |
||||
|
||||
.. code-block:: none |
||||
|
||||
volume-b45066d3-931d-406e-a43e-ad4eca12cf34 |
||||
volume-dd733b26-2c56-4355-a8fc-347a964d5d55 |
||||
|
||||
Step 1: Deploy new topology |
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
Deploy the ``cinder-ceph`` charm and set the 'rbd-pool-name' to match the pool |
||||
that any existing volumes are in (see above): |
||||
|
||||
.. code-block:: none |
||||
|
||||
juju deploy --config rbd-pool-name=cinder cinder-ceph |
||||
juju add-relation cinder cinder-ceph |
||||
juju add-relation cinder-ceph ceph-mon |
||||
juju remove-relation cinder ceph-mon |
||||
juju add-relation cinder-ceph nova-compute |
||||
|
||||
Step 2: Update volume configuration |
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
The existing volumes now need to be updated to associate them with the newly |
||||
defined cinder-ceph backend: |
||||
|
||||
.. code-block:: none |
||||
|
||||
juju run-action cinder/0 rename-volume-host currenthost='cinder' \ |
||||
newhost='cinder@cinder-ceph#cinder.volume.drivers.rbd.RBDDriver' |
||||
@ -0,0 +1,35 @@
|
||||
:orphan: |
||||
|
||||
======================== |
||||
Upgrade: Queens to Rocky |
||||
======================== |
||||
|
||||
This page contains notes specific to the Queens to Rocky upgrade path. See the |
||||
main :doc:`upgrade-openstack` page for full coverage. |
||||
|
||||
Keystone and Fernet tokens |
||||
-------------------------- |
||||
|
||||
Starting with OpenStack Rocky only the Fernet format for authentication tokens |
||||
is supported. Therefore, prior to upgrading Keystone to Rocky a transition must |
||||
be made from the legacy format (of UUID) to Fernet. |
||||
|
||||
Fernet support is available upstream (and in the keystone charm) starting with |
||||
Ocata so the transition can be made on either Ocata, Pike, or Queens. |
||||
|
||||
A keystone charm upgrade will not alter the token format. The charm's |
||||
``token-provider`` option must be used to make the transition: |
||||
|
||||
.. code-block:: none |
||||
|
||||
juju config keystone token-provider=fernet |
||||
|
||||
This change may result in a minor control plane outage but any running |
||||
instances will remain unaffected. |
||||
|
||||
The ``token-provider`` option has no effect starting with Rocky, where the |
||||
charm defaults to Fernet and where upstream removes support for UUID. See |
||||
`Keystone Fernet Token Implementation`_ for more information. |
||||
|
||||
.. LINKS |
||||
.. _Keystone Fernet Token Implementation: https://specs.openstack.org/openstack/charm-specs/specs/rocky/implemented/keystone-fernet-tokens.html |
||||
@ -0,0 +1,25 @@
|
||||
:orphan: |
||||
|
||||
=========================== |
||||
Upgrade: Ussuri to Victoria |
||||
=========================== |
||||
|
||||
This page contains notes specific to the Ussuri to Victoria upgrade path. See |
||||
the main :doc:`upgrade-openstack` page for full coverage. |
||||
|
||||
FWaaS project retired |
||||
--------------------- |
||||
|
||||
The Firewall-as-a-Service (`FWaaS v2`_) OpenStack project is retired starting |
||||
with OpenStack Victoria. Consequently, the neutron-api charm will no longer |
||||
make this service available starting with that OpenStack release. See the |
||||
`21.10 release notes`_ on this topic. |
||||
|
||||
Prior to upgrading to Victoria users of FWaaS should remove any existing |
||||
firewall groups to avoid the possibility of orphaning active firewalls (see the |
||||
`FWaaS v2 CLI documentation`_). |
||||
|
||||
.. LINKS |
||||
.. _21.10 release notes: https://docs.openstack.org/charm-guide/latest/2110.html |
||||
.. _FWaaS v2: https://docs.openstack.org/neutron/ussuri/admin/fwaas.html |
||||
.. _FWaaS v2 CLI documentation: https://docs.openstack.org/python-neutronclient/ussuri/cli/osc/v2/firewall-group.html |
||||
Loading…
Reference in new issue