diff --git a/doc/source/dist_cloud/kubernetes/subclouds-previous-release-management-5e986615cb4b.rst b/doc/source/dist_cloud/kubernetes/subclouds-previous-release-management-5e986615cb4b.rst index 1d4f5a4a5..d427aa32c 100644 --- a/doc/source/dist_cloud/kubernetes/subclouds-previous-release-management-5e986615cb4b.rst +++ b/doc/source/dist_cloud/kubernetes/subclouds-previous-release-management-5e986615cb4b.rst @@ -23,8 +23,8 @@ Subclouds Previous Major Release Management .. note:: - This capability is not available for |prod| |v_r7|. If the system - controller is on |prod| |v_r8|, subclouds can be deployed or restored to + This capability is not available for |prod| |v_r7|. If the System + Controller is on |prod| |v_r8|, subclouds can be deployed or restored to either |prod| |v_r8| or |prod| |v_r6|. .. contents:: |minitoc| @@ -136,7 +136,7 @@ To support subcloud install or subcloud restore to either the current (N) or previous (N-1) release, ensure that the following prerequisites are met: - The N load (pre-patched ISO) containing this capability must be imported to - the system controller using the :command:`software --os-region-name SystemController upload` + the System Controller using the :command:`software --os-region-name SystemController upload` command. The ISO imported should be at the same patch level as the system controller. This requirement ensures that the subcloud boot image is aligned with the patch level of the load to be installed on the subcloud. @@ -144,7 +144,7 @@ previous (N-1) release, ensure that the following prerequisites are met: .. note:: - Each time a new patch is applied on the system controller, it is + Each time a new patch is applied on the System Controller, it is necessary to re-upload the new pre-patched ISO containing the same patch(es). @@ -160,7 +160,7 @@ previous (N-1) release, ensure that the following prerequisites are met: .. _n-1-load-uploaded-system-controller: -- The N-1 load (pre-patched ISO) must be uploaded to the system controller +- The N-1 load (pre-patched ISO) must be uploaded to the System Controller using the the following command: .. code-block:: none @@ -192,14 +192,14 @@ previous (N-1) release, ensure that the following prerequisites are met: subcloud installation failure, as the persistent ``/opt/platform-backup`` partition cannot be reduced in size. -- If the system controller was installed with default settings, it will use +- If the System Controller was installed with default settings, it will use the latest Kubernetes version for the release it's running. To support - upgrading the subcloud, ensure that the system controller has locally + upgrading the subcloud, ensure that the System Controller has locally stored copies (caches) of container images for all the previous versions of Kubernetes relevant to the platform release. For example, if the system controller is installed with Kubernetes 1.24, we need to ensure that all the system images related to Kubernetes 1.21, 1.22, and 1.23 are stored - locally (cached) on the system controller for use when the subcloud tries + locally (cached) on the System Controller for use when the subcloud tries to upgrade to those versions. To obtain more information about the list of images, see the corresponding @@ -289,7 +289,7 @@ run the following command: .. note:: - If controller-1 of the system controller is the active controller, make + If controller-1 of the System Controller is the active controller, make sure that `/var/www/pages/feed/rel-` exists before deploying a |prod| |v_r6| subcloud. Use the :command:`scp` command to copy the entire directory from controller-0 to controller-1. @@ -310,7 +310,7 @@ Where, is the |prod| |v_r6| major version. .. note:: If the ``--release`` option is not specified, the subcloud will be deployed - to the current major release of the system controller. + to the current major release of the System Controller. .. warning:: @@ -568,10 +568,10 @@ ID specified. Rehome a Subcloud ----------------- -N-1 subclouds can be migrated to another system controller running N software +N-1 subclouds can be migrated to another System Controller running N software release. Use the :command:`dcmanager subcloud add --migrate` command with the ``--release`` option to rehome a subcloud. It is not possible to migrate a -subcloud running N software release to a system controller running N-1 software +subcloud running N software release to a System Controller running N-1 software release. .. note:: @@ -583,22 +583,21 @@ release. **See**: :ref:`Backup a Subcloud/Group of Subclouds using DCManager CLI ` -Rehome |prod| |v_r6| Subcloud to |prod| |v_r8| System Controller -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Rehome |prod| N-1 Major Release Subcloud to |prod| N Major Release System Controller +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To migrate |prod| |v_r6| subcloud from system controller A to system controller -B running |prod| |v_r8|, ensure that the |prod| |v_r6| pre-patched ISO has been -imported to System Controller B as an inactive load, and follow the |prod| -|v_r6| subcloud rehome procedure as follows: +To migrate |prod| N-1 subcloud from System Controller A to System Controller B +running |prod| N, ensure that the |prod| N-1 pre-patched ISO has been imported +to System Controller B as an inactive load, and follow the |prod| N subcloud +rehome procedure as follows: -#. Unmanage the subcloud from the previous system controller. +#. Unmanage the subcloud from the previous System Controller. -#. Update the admin password on the subcloud to match the new system - controller, if required. +#. Update the admin password on the subcloud to match the new System + Controller, if required. #. Run the :command:`dcmanager subcloud add` command on the new System - Controller with the ``--migrate`` and ``--release`` options to initiate the - migration: + Controller with the ``--migrate`` and ``--release`` option to initiate the migration: .. code-block:: none @@ -607,7 +606,7 @@ imported to System Controller B as an inactive load, and follow the |prod| --bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml --release - Where, is the |prod| |v_r6| version. + Where, is the |prod| N-1 version. #. On the subcloud, lock/unlock the subcloud controller(s) to enable the new configuration. @@ -616,23 +615,22 @@ imported to System Controller B as an inactive load, and follow the |prod| status. Ensure that the subcloud is online and fully operational before proceeding to manage the subcloud. -#. On the new system controller, set the subcloud to ``managed`` and wait for +#. On the new System Controller, set the subcloud to ``managed`` and wait for it to sync. -#. Delete the subcloud from the previous system controller. +#. Delete the subcloud from the previous System Controller. For more detailed information, refer to the `Rehome-a-Subcloud `_ -topic in the |prod| |v_r6| documentation. +topic in the |prod| N documentation. -Rehome |prod| |v_r8| Subcloud to |prod| |v_r8| System Controller -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Rehome |prod| N Major Release Subcloud to |prod| N Major Release System Controller +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For more detailed information, see :ref:`rehoming-a-subcloud`. .. note:: - You can add the ``--release `` option to the :command:`dcmanager - subcloud add --migrate` command but it is not mandatory. + You can add the ``--release `` option to the :command:`dcmanager subcloud add --migrate` command but it is not mandatory. - Where, is the |prod| |v_r8| version. + Where, is the |prod| N version.