From 9967a8f91b22a06cf81c4c97ca2617941149ac8e Mon Sep 17 00:00:00 2001 From: Peter Matulis Date: Thu, 31 Aug 2023 15:35:59 -0400 Subject: [PATCH] Fix described hacluster behaviour for series upgrades Correct documented steps that suggest that pausing hacluster units during a series upgrade makes a difference in terms of preventing downtime. This has not been the case since early 2020 (commit-wise). Closes-Bug: #2033546 Relates-To: Id9167534e8933312c561a6acba40399bca437706 Change-Id: I6bbfc14a445a972eb48aab8894d633f1aa5a5e6f Signed-off-by: Peter Matulis --- .../admin/upgrades/series-openstack.rst | 40 +++---------------- 1 file changed, 5 insertions(+), 35 deletions(-) diff --git a/doc/source/admin/upgrades/series-openstack.rst b/doc/source/admin/upgrades/series-openstack.rst index d6fbecf4..a5a1c89d 100644 --- a/doc/source/admin/upgrades/series-openstack.rst +++ b/doc/source/admin/upgrades/series-openstack.rst @@ -36,11 +36,9 @@ When machines associated with a single API application undergo a series upgrade that individual API will also experience downtime. This is because it is necessary to pause services in order to avoid race condition errors. -For those applications working in tandem with hacluster, as will be shown, some -hacluster units will need to be paused before the upgrade. One should assume -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). +A clustered application, working in tandem with hacluster, will be unavailable +during a series upgrade. The service VIP will go offline due to the resource +management software being shut down. Generalised OpenStack series upgrade ------------------------------------ @@ -81,9 +79,6 @@ The steps are as follows: #. Set the default series for the principal application. -#. If hacluster is used, pause the hacluster units not associated with the - principal leader machine. - #. Pause the principal non-leader units. #. Perform a series upgrade on each of the paused machines: @@ -426,13 +421,6 @@ machine 0/lxd/1 (the principal leader machine). juju set-series percona-cluster bionic -#. Pause the hacluster units not associated with the principal leader machine: - - .. code-block:: none - - juju run --wait percona-cluster-hacluster/0 pause - juju run --wait percona-cluster-hacluster/1 pause - #. Pause the principal non-leader units: .. code-block:: none @@ -477,7 +465,7 @@ machine 0/lxd/1 (the principal leader machine). juju upgrade-series 0/lxd/1 complete -#. Repeat step 4 for each of the principal non-leader machines: +#. Repeat step 3 for each of the principal non-leader machines: .. code-block:: none @@ -587,13 +575,6 @@ In summary, the principal leader unit is keystone/0 and is deployed on machine juju set-series keystone bionic -#. Pause the hacluster units not associated with the principal leader machine: - - .. code-block:: none - - juju run --wait keystone-hacluster/0 pause - juju run --wait keystone-hacluster/1 pause - #. Pause the principal non-leader units: .. code-block:: none @@ -747,16 +728,6 @@ In summary, juju set-series glance bionic juju set-series nova-cloud-controller bionic -#. Pause the hacluster units not associated with their principal leader - machines: - - .. code-block:: none - - juju run --wait glance-hacluster/1 pause - juju run --wait glance-hacluster/2 pause - juju run --wait nova-cloud-controller-hacluster/1 pause - juju run --wait nova-cloud-controller-hacluster/2 pause - #. Pause the principal non-leader units: .. code-block:: none @@ -943,8 +914,7 @@ arrive at the following output: In summary, the ceph-osd and nova-compute applications are hosted on machine 1. Since application leadership does not play a significant role with these two -applications, and because the hacluster application is not present, there will -be no units to pause. +applications there will be no units to pause. .. important::