openstack
/
charm-deployment-guide
Code Issues Proposed changes

Improve upgrade overview 

Improve and streamline upgrade overview text.

In particular, move the topology information to the
upgrade-overview page.

Related-Bug: #1929091
Change-Id: If8bb494966915c34f50a23937f3b500ed99c7049
This commit is contained in:
Peter Matulis 2022-05-06 12:25:37 -04:00
parent 70a2ebe80f
commit 8707712087
2 changed files with 29 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
deploy-guide/source/upgrade-overview.rst
View File

@ -28,6 +28,35 @@ Series upgrade
across the cloud. Operating a cloud consisting of partially upgraded
components is not tested nor supported.
Cloud topology
--------------
All upgrade procedures assume a specific hyperconverged cloud topology.
.. caution::
Any deviation from the described topology may require adjustments to the
given procedural steps. In particular, look at differences in co-located
principal applications.
The topology is defined in this way:
* Only compute and storage charms (and their subordinates) are co-located.
* Third-party charms either do not exist or have been thoroughly tested for all
three upgrade types.
* The following services run in LXD containers:
* all API applications
* the database application (percona-cluster or mysql-innodb-cluster)
* the rabbitmq-server application
* the ceph-mon application
* All applications, where possible, are under high availability, whether
natively (e.g. ceph-mon, rabbitmq-server) or via hacluster (e.g.
keystone).
Development notes
-----------------

49
deploy-guide/source/upgrade-series-openstack.rst
View File

@ -36,55 +36,6 @@ that the commencement of an outage coincides with this step (it will cause
cluster quorum heartbeats to fail and the service VIP will consequently go
offline).
Reference cloud topology
------------------------
This section describes a hyperconverged cloud topology that this document will
use for the procedural steps to follow. Hyperconvergence refers to the practice
of co-locating principal applications on the same machine.
The topology is defined in this way:
* Only compute and storage charms (and their subordinates) may be co-located.
* Third-party charms either do not exist or have been thoroughly tested for a
series upgrade.
* The following are containerised:
* All API applications
* The percona-cluster application
* The rabbitmq-server application
* The ceph-mon application
* All applications, where possible, are under high availability, whether
natively (e.g. ceph-mon, rabbitmq-server) or via hacluster (e.g.
percona-cluster).
.. caution::
If your cloud differs from this topology you must adapt the procedural steps
accordingly. In particular, look at the aspects of co-located applications
and containerised applications. Recall that:
* the :command:`upgrade-series` command:
* affects all applications residing on the target machine
* does not affect containers hosted on the target machine
Notes
~~~~~
Storage charms are charms that manage physical disks. For example, ceph-osd and
swift-storage.
Example OpenStack subordinate charms are networking SDN charms for the
nova-compute charm, or monitoring charms for compute or storage charms.
Generalised OpenStack series upgrade
------------------------------------