starlingx/docs
Code Issues Proposed changes
docs/doc/source/updates/kubernetes/rolling-back-a-software-upgrade-after-the-second-controller-upgrade.rst
Ron Stone 0012d76f09 Add updates and upgrades content 
Some substitutions also added to accomodate StX vs partner file naming.
Add 750.006 alarm to performing-an-orchestrated-upgrade

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: I33588f3c1b22cd0dbc96133cf8eb056c8c2e5162
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
2021-05-17 07:12:27 -04:00

3.2 KiB
Raw Blame History

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.

  1. Run the upgrade-abort command to abort the upgrade.

    $ 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 system upgrade-abort is executed after upgrading controller-0.
      • Remain in this state until the abort is completed.

  2. Make controller-1 active.

    $ system host-swact controller-0

  3. Lock controller-0.

    $ system host-lock controller-0

  4. Wipe the disk and power down all storage (if applicable) and worker hosts.

    Note

    Skip this step if doing this procedure on a Duplex system.

    1. Execute wipedisk from the shell on each storage or worker host.
    2. Power down each host.

  5. Lock all storage (if applicable) and worker hosts.

    Note

    Skip this step if doing this procedure on a Duplex system.

    $ system host-lock <hostID>

  6. Downgrade controller-0.

    $ system host-downgrade controller-0

    The host is re-installed with the previous release load.

  7. Unlock controller-0.

    $ system host-unlock controller-0

  8. Swact to controller-0.

    $ 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.

  9. Lock and downgrade controller-1.

    $ system host-downgrade controller-1

    The host is re-installed with the previous release load.

  10. Unlock controller-1.

    $ system host-unlock controller-1

  11. Power up and unlock the storage hosts one at a time (if using a Ceph storage backend). The hosts are re-installed with the release N load.

    Note

    Skip this step if doing this procedure on a Duplex system.

  12. Power up and unlock the worker hosts one at a time.

    Note

    Skip this step if doing this procedure on a 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.

  13. Complete the upgrade.

    $ system upgrade-complete

    This cleans up the upgrade release, configuration, databases, and so forth.

  14. Delete the upgrade release load.

    $ system load-delete