Re-enable unattended upgrades

Add a last step to the upgrade openstack procedure.

This PR will also be used to generate an OpenStack
Xena version of the CDG (via a backport to stable/xena).

Change-Id: I98eedee692d94b0d9dfa992c50f49727123bc174
(cherry picked from commit 7a5914976f70b86bd41d1a772f01f851f70b8191)
This commit is contained in:
Peter Matulis 2021-10-26 15:50:15 -04:00
parent f6cbe0e747
commit 155ff94e43

@ -68,6 +68,8 @@ battery of operational checks on the cloud.
This step is to make certain that any issues that may appear after the upgrade This step is to make certain that any issues that may appear after the upgrade
are not due to pre-existing problems. are not due to pre-existing problems.
.. _disable_unattended_upgrades:
Disable unattended-upgrades Disable unattended-upgrades
--------------------------- ---------------------------
@ -474,6 +476,18 @@ Victoria where ``keystone/2`` is the leader:
unit number. As in the above example, only for keystone/0 do the unit unit number. As in the above example, only for keystone/0 do the unit
numbers correspond (i.e. keystone-hacluster/0 is the subordinate unit). numbers correspond (i.e. keystone-hacluster/0 is the subordinate unit).
Re-enable unattended-upgrades
-----------------------------
In a :ref:`previous step <disable_unattended_upgrades>`, unattended-upgrades
were disabled on those cloud nodes that hosted multiple principle charms. Once
such a node has had all of its services upgraded, unattended-upgrades should be
re-enabled:
.. code-block:: none
sudo dpkg-reconfigure -plow unattended-upgrades
Verify the new deployment Verify the new deployment
------------------------- -------------------------