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:
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
|
||||
-------------------------
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user