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
are not due to pre-existing problems.
.. _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
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
-------------------------