Add placement charm to special procedures

* Retitle 'Special charm upgrade procedures' to
  'Special charm procedures' to make it sound more
  general. Reword the opening paragraph to be more
  concise and more accurate.

* Move the introduction of the placement charm from
  the 'Known issues' page (and re-worded slightly)
  to the 'Special charm procedures' page. Make it clear
  that the former page is for software limitations/bugs.

* Add the 'Special charm procedures' page to the list
  of resources to read on several of the upgrade pages.

* Add the 'Upgrade issues' page to the list of resources
  to read on the 'Upgrade charms' page.

Change-Id: I51f57ee5a4c29527d3306d2b082a89cd77f1aec9
This commit is contained in:
Peter Matulis 2021-02-22 20:32:19 -05:00
parent d2ef4be577
commit b704d78206
6 changed files with 63 additions and 49 deletions

View File

@ -0,0 +1,48 @@
:orphan:
===========================================
placement charm: OpenStack upgrade to Train
===========================================
As of OpenStack Train, the Placement API is managed by the new `placement`_
charm and is no longer managed by the nova-cloud-controller charm. The upgrade
to Train therefore involves some coordination to transition to the new API
endpoints.
Prior to upgrading nova-cloud-controller services to Train, the placement charm
must be deployed for Train and related to the Stein-based nova-cloud-controller
application. It is important that the nova-cloud-controller unit leader is
paused while the API transition occurs (paused prior to adding relations for
the placement charm) as the placement charm will migrate existing placement
tables from the nova_api database to a new placement database. Once the new
placement endpoints are registered, nova-cloud-controller can be resumed.
Here are example commands for the process just described:
.. code-block:: none
juju deploy --series bionic --config openstack-origin=cloud:bionic-train placement
juju run-action --wait nova-cloud-controller/leader pause
juju add-relation placement percona-cluster
juju add-relation placement keystone
juju add-relation placement nova-cloud-controller
List endpoints and ensure placement endpoints are now listening on the new
placment IP address. Follow this up by resuming nova-cloud-controller:
.. code-block:: none
openstack endpoint list
juju run-action --wait nova-cloud-controller/leader resume
Finally, upgrade the nova-cloud-controller services. Below all units are
upgraded simultaneously but see the `paused-single-unit`_ service upgrade
method for a more controlled approach:
.. code-block:: none
juju config nova-cloud-controller openstack-origin=cloud:bionic-train
.. LINKS
.. _placement: https://jaas.ai/placement
.. _paused-single-unit: upgrade-openstack.html#paused-single-unit

View File

@ -10,6 +10,8 @@ Please read the following before continuing:
* the :doc:`Upgrades overview <upgrade-overview>` page
* the OpenStack charms `Release Notes`_ for the corresponding current and
target versions of OpenStack
* the :doc:`Special charm procedures <upgrade-special>` page
* the :doc:`Upgrade issues <upgrade-issues>` page
.. note::

View File

@ -2,8 +2,8 @@
Known upgrade issues
====================
This section documents known issues that may apply to either of the three
upgrade types (charms, OpenStack, series).
This section documents known issues (software limitations/bugs) that may apply
to either of the three upgrade types (charms, OpenStack, series).
DNS HA with the focal series
----------------------------
@ -116,43 +116,6 @@ 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.
Placement charm and nova-cloud-controller: upgrading from Stein to Train
------------------------------------------------------------------------
As of Train, the placement API is managed by the new ``placement`` charm and is
no longer managed by the ``nova-cloud-controller`` charm. The upgrade to Train
therefore requires some coordination to transition to the new API endpoints.
Prior to upgrading nova-cloud-controller to Train, the placement charm must be
deployed for Train and related to the Stein-based nova-cloud-controller. It is
important that the nova-cloud-controller unit leader is paused while the API
transition occurs (paused prior to adding relations for the placement charm) as
the placement charm will migrate existing placement tables from the nova_api
database to a new placement database. Once the new placement endpoints are
registered, nova-cloud-controller can be resumed.
Here's an example of the steps just described where `nova-cloud-controller/0`
is the leader:
.. code-block:: none
juju deploy --series bionic --config openstack-origin=cloud:bionic-train cs:placement
juju run-action nova-cloud-controller/0 pause
juju add-relation placement mysql
juju add-relation placement keystone
juju add-relation placement nova-cloud-controller
openstack endpoint list # ensure placement endpoints are listening on new placment IP address
juju run-action nova-cloud-controller/0 resume
Only after these steps have been completed can nova-cloud-controller be
upgraded. Here we upgrade all units simultaneously but see the
ref:`paused-single-unit <paused_single_unit>` service upgrade method for a more
controlled approach:
.. code-block:: none
juju config nova-cloud-controller openstack-origin=cloud:bionic-train
Neutron LBaaS: upgrading from Stein to Train
--------------------------------------------

View File

@ -14,6 +14,7 @@ Please read the following before continuing:
* the :doc:`Upgrades overview <upgrade-overview>` page
* the OpenStack charms `Release Notes`_ for the corresponding current and
target versions of OpenStack
* the :doc:`Special charm procedures <upgrade-special>` page
* the :doc:`Upgrade issues <upgrade-issues>` page
.. note::

View File

@ -12,6 +12,7 @@ Please read the following before continuing:
* the :doc:`Upgrades overview <upgrade-overview>` page
* the OpenStack charms `Release Notes`_ for the corresponding current and
target versions of OpenStack
* the :doc:`Special charm procedures <upgrade-special>` page
* the :doc:`Upgrade issues <upgrade-issues>` page
Once this document has been studied the administrator will be ready to graduate

View File

@ -1,15 +1,14 @@
================================
Special charm upgrade procedures
================================
========================
Special charm procedures
========================
The OpenStack charms are designed to accommodate every supported series and
OpenStack release wherever possible. However, upgrades may occasionally
introduce unavoidable challenges for a deployed charm. For instance, it could
be that a charm is replaced by an entirely new charm on the new series. This
can happen due to development policy concerning the charms themselves or due to
reasons independent of the charms (e.g. the workload software is no longer
supported on the new operating system). Any core OpenStack charms affected in
this way will be documented here:
OpenStack release wherever possible. However, upgrades (of either of the three
types) may occasionally introduce unavoidable challenges. For instance, it
could be that a charm is replaced by an entirely new charm on a new series or a
new charm is needed to accommodate a new service on a new OpenStack release.
These kinds of special procedures are documented here:
* :doc:`percona-cluster charm: series upgrade to focal <percona-series-upgrade-to-focal>`
* :doc:`placement charm: OpenStack upgrade to Train <placement-charm-upgrade-to-train>`
* :doc:`ceph charm: migration to ceph-mon and ceph-osd <app-ceph-migration>`