4aef0abb31
Updated topic 'Abort Simplex System Upgrades' as detailed in jira Updated topics from distributed and updates guides -information from doc provided by David https://review.opendev.org/c/starlingx/docs/+/794309 Signed-off-by: Adil <mohamed.adilassakkali@windriver.com> Change-Id: Id47e93f1c57e579dca483e8d073902f933ef78bf
146 lines
3.9 KiB
ReStructuredText
146 lines
3.9 KiB
ReStructuredText
|
||
.. eiu1593277809293
|
||
.. _rolling-back-a-software-upgrade-after-the-second-controller-upgrade:
|
||
|
||
================================================================
|
||
Roll Back a Software Upgrade After the Second Controller Upgrade
|
||
================================================================
|
||
|
||
After the second controller is upgraded, you can still roll back a software
|
||
upgrade, however, the rollback will impact the hosting of applications.
|
||
|
||
The upgrade abort procedure can only be applied before the
|
||
:command:`upgrade-complete` command is issued. Once this command is issued
|
||
the upgrade can not be aborted. If the return to the previous release is required,
|
||
then restore the system using the backup data taken prior to the upgrade.
|
||
|
||
In some scenarios additional actions will be required to complete the upgrade
|
||
abort. It may be necessary to restore the system from a backup.
|
||
|
||
.. rubric:: |proc|
|
||
|
||
#. Run the :command:`upgrade-abort` command to abort the upgrade.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system upgrade-abort
|
||
|
||
Once this is done there is no going back; the upgrade must be completely
|
||
aborted.
|
||
|
||
The following state applies when you run this command.
|
||
|
||
- aborting-reinstall:
|
||
|
||
- State entered when :command:`system upgrade-abort` is executed
|
||
after upgrading controller-0.
|
||
|
||
- Remain in this state until the abort is completed.
|
||
|
||
#. Make controller-1 active.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-swact controller-0
|
||
|
||
#. Lock controller-0.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-lock controller-0
|
||
|
||
#. Wipe the disk and power down all storage \(if applicable\) and worker hosts.
|
||
|
||
.. note::
|
||
Skip this step if doing this procedure on a |prod| Duplex system.
|
||
|
||
#. Execute :command:`wipedisk` from the shell on each storage or worker
|
||
host.
|
||
|
||
#. Power down each host.
|
||
|
||
#. Lock all storage \(if applicable\) and worker hosts.
|
||
|
||
.. note::
|
||
Skip this step if doing this procedure on a |prod| Duplex system.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-lock <hostID>
|
||
|
||
#. Downgrade controller-0.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-downgrade controller-0
|
||
|
||
The host is re-installed with the previous release load.
|
||
|
||
#. Unlock controller-0.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-unlock controller-0
|
||
|
||
.. note::
|
||
Wait for controller-0 to become unlocked-enabled. Wait for the
|
||
|DRBD| sync 400.001 Services-related alarm to be raised and then cleared.
|
||
|
||
#. Swact to controller-0.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-swact controller-1
|
||
|
||
Swacting back to controller-0 will switch back to using the previous
|
||
release databases, which were frozen at the time of the swact to
|
||
controller-1. This is essentially the same result as a system restore.
|
||
|
||
#. Lock and downgrade controller-1.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-lock controller-1
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-downgrade controller-1
|
||
|
||
The host is re-installed with the previous release load.
|
||
|
||
#. Unlock controller-1.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system host-unlock controller-1
|
||
|
||
|
||
#. Power up and unlock the storage hosts one at a time \(if using a Ceph
|
||
storage backend\). The hosts are re-installed with the previous release load.
|
||
|
||
.. note::
|
||
Skip this step if doing this procedure on a |prod| Duplex system.
|
||
|
||
#. Power up and unlock the worker hosts one at a time.
|
||
|
||
.. note::
|
||
Skip this step if doing this procedure on a |prod| Duplex system.
|
||
|
||
The hosts are re-installed with the previous release load. As each worker
|
||
host goes online, application pods will be automatically recovered by the
|
||
system.
|
||
|
||
#. Complete the upgrade.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system upgrade-complete
|
||
|
||
This cleans up the upgrade release, configuration, databases, and so forth.
|
||
|
||
#. Delete the upgrade release load.
|
||
|
||
.. code-block:: none
|
||
|
||
$ system load-delete
|