Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add explanation for different upgrade strategies #323

Merged
merged 1 commit into from
Mar 22, 2024
Merged

Add explanation for different upgrade strategies #323

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/.custom_wordlist.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,3 +42,4 @@ barbican
mysql
innodb
colocated
minimize
30 changes: 27 additions & 3 deletions docs/explanation/upgrade.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,30 @@ Upgrade
=======

This phase is responsible for applying the upgrade plan step by step (see
:doc:`Upgrade a cloud <../how-to/upgrade-cloud>`). Most steps will be applied
sequentially, but for some that are defined to be run in parallel, they will be
executed in such a way.
:doc:`Upgrade a cloud <../how-to/upgrade-cloud>`).

For the **control-plane**, COU upgrades applications in a strict sequential
manner, following a predefined order (see :doc:`Upgrade groups <./upgrade-groups>`) and
halting the process should any application encounter an upgrade failure. All
gabrielcocenza marked this conversation as resolved.
Show resolved Hide resolved
applications within the **control-plane** employ an `all-in-one`_ method, upgrading
all units of an application simultaneously.

COU adopts a more cautious strategy when upgrading **data-plane** applications to
minimize the risk of downtime, which can occur if the unit undergoing upgrade is
actively handling client requests. Between applications, similar to the
agileshaw marked this conversation as resolved.
Show resolved Hide resolved
**control-plane**, upgrades are executed sequentially following the predefined order
(see :doc:`Upgrade groups <./upgrade-groups>`). But for applications that support the
**openstack-upgrade** action (such as **nova-compute** and its colocated services like
**cinder**), COU handles the upgrades in a `paused-single-unit`_ fashion. This method
is notably more time-intensive, so to streamline the process while still maintaining
cloud stability, units are grouped based on the Juju availability zones of their
respective hosting machines. COU then progresses through these availability zone groups
in a sequential manner, performing upgrades on units within a single zone in parallel.

**Note:** **ceph-osd**, while being a component of the **data-plane**, employs the
*all-in-one* method for upgrades. because its charm is designed to maintain service
availability throughout the upgrade process.

.. LINKS
.. _all-in-one: https://docs.openstack.org/charm-guide/latest/admin/upgrades/openstack.html#perform-the-upgrade
.. _paused-single-unit: https://docs.openstack.org/charm-guide/latest/admin/upgrades/openstack.html#perform-the-upgrade
Loading