diff --git a/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst b/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst index cdbca12b9..5d112dad2 100644 --- a/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst +++ b/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst @@ -34,7 +34,7 @@ follows: .. rubric:: |prereq| -For all deployment configurations, end user container images in +For |AIO-SX| deployment configurations, the end user container images in `registry.local` will be backed up during the upgrade process. This only includes images other than |prod| system and application images. These images are limited to 5 GB in total size. If the system contains more than 5 GB of @@ -66,16 +66,18 @@ The following prerequisites apply to a |prod-dc| upgrade management service. - Run the :command:`kubectl get pods --all-namespaces` command to test that the authentication token validates correctly. - - Run the :command:`fm alarm-list` command to check the system health to - ensure that there are no unexpected or management-affecting alarms. + - Run the :command:`fm alarm-list` command to ensure that there are no + unexpected or management-affecting alarms. + + - Run the :command:`system health-query-upgrade` command to check the + system health to ensure that the system meets all the upgrade prerequisites. - Run the :command:`kubectl get host -n deployment` command to ensure all nodes in the cluster have reconciled and is set to 'true'. - Ensure **controller-0** is the active controller. -- The subclouds must all be |AIO-SX|, and must use the Redfish - platform management service. +- The |AIO-SX| subclouds must use the Redfish platform management service. - Ensure any certificates managed by cert manager will not be renewed during the upgrade process. diff --git a/doc/source/dist_cloud/kubernetes/upgrading-the-systemcontroller-using-the-cli.rst b/doc/source/dist_cloud/kubernetes/upgrading-the-systemcontroller-using-the-cli.rst index 4aecd0aac..885d1ed78 100644 --- a/doc/source/dist_cloud/kubernetes/upgrading-the-systemcontroller-using-the-cli.rst +++ b/doc/source/dist_cloud/kubernetes/upgrading-the-systemcontroller-using-the-cli.rst @@ -173,12 +173,11 @@ Follow the steps below to manually upgrade the system controller: Use the command :command:`system upgrade-start --force` to force the upgrades process to start and to ignore management affecting alarms. - This should ONLY be done if these alarms do not cause an issue for the + This should only be done if these alarms do not cause an issue for the upgrades process. - The `fm alarm-list` will provide the specific alarms leading to the system - health-query-upgrade alarms notes which may be blocking an orchestrated - upgrade. + The ``fm alarm-list --mgmt_affecting`` option provides specific alarms + which may be blocking an orchestrated upgrade. On systems with Ceph storage, it also checks that the Ceph cluster is healthy. @@ -254,9 +253,8 @@ Follow the steps below to manually upgrade the system controller: .. note:: - Do not unlock controller-1, before running :command:`system - upgrade-show` to display the upgrade status - "data-migration-complete". + Do not unlock controller-1, before running the :command:`system upgrade-show` + command to display the upgrade status **data-migration-complete** or **upgrading-controllers**. #. Unlock controller-1. @@ -268,18 +266,11 @@ Follow the steps below to manually upgrade the system controller: the DRBD sync **400.001** Services-related alarm has been raised and then cleared. - The following states apply when this command is executed. - - - - upgrading-controllers: - - - - State entered when controller-1 has been unlocked and is - running release nn.nn software. - - where *nn.nn* in the update file name is the |prod| release - number. + The **upgrading-controllers** state applies when this command is + run. This state is entered after controller-1 has been upgraded to + release nn.nn and data migration is successfully completed. + where *nn.nn* in the update file name is the |prod| release number. If it transitions to **unlocked-disabled-failed**, check the issue before proceeding to the next step. The alarms may indicate a @@ -287,8 +278,8 @@ Follow the steps below to manually upgrade the system controller: controller-1, (for example, Error logs in controller1:``/var/log/puppet``). - #. Run the :command:`system application-list`, and :command:`system - host-upgrade-list` commands to view the current progress. + #. Run the :command:`system application-list` and :command:`system host-upgrade-list` + commands to view the current progress. #. Set controller-1 as the active controller. Swact to controller-1. diff --git a/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst b/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst index 805c54f29..aa77d2899 100644 --- a/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst +++ b/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst @@ -312,12 +312,9 @@ of |prod| software. the |DRBD| sync **400.001** Services-related alarm to be raised and then cleared. - The following states apply when this command is executed. - - - ``upgrading-controllers``: - - - State entered when controller-1 has been unlocked and is - running release nn.nn software. + The **upgrading-controllers** state applies when this command is executed. + This state is entered after controller-1 has been upgraded to release nn.nn + and data migration is successfully completed. If the controller transitions to **unlocked-disabled-failed**, check the issue before proceeding to the next step. The alarms may indicate a