Merge "Upgrade Support doc update (r10.1)"

doc/source/_vendor/rl-strings.txt

@@ -37,7 +37,7 @@
 .. |index-dist-cloud-f5dbeb16b976| replace:: :ref:`Distributed Cloud <index-dist-cloud-f5dbeb16b976>`
 .. |certificate-management-for-admin-rest-api-endpoints| replace:: :ref:`Certificate Management for Admin REST API Endpoints <certificate-management-for-admin-rest-api-endpoints>`
 .. |installing-a-subcloud-using-redfish-platform-management-service| replace:: :ref:`Install a Subcloud Using Redfish Platform Management Service <installing-a-subcloud-using-redfish-platform-management-service>`
-.. |aborting-the-distributed-upgrade-orchestration| replace:: :ref:`Aborting the Distributed Upgrade Orchestration <aborting-the-distributed-upgrade-orchestration>`
+.. |abort-the-distributed-software-deploy-orchestration| replace:: :ref:`Abort the Distributed Software Deploy Orchestration <abort-the-distributed-software-deploy-orchestration>`
 .. |installing-and-provisioning-a-subcloud| replace:: :ref:`Install and Provision a Subcloud <installing-and-provisioning-a-subcloud>`
 .. |migrate-an-aiosx-subcloud-to-an-aiodx-subcloud| replace:: :ref:`Reconfigure the Cluster-Host Interface <migrate-an-aiosx-subcloud-to-an-aiodx-subcloud>`
 .. |deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b| replace:: :ref:`Deploy, Restore, and Manage Subclouds of Previous Release <deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b>`
@@ -53,7 +53,7 @@
 .. |the-kubernetes-distributed-cloud-update-orchestration-process| replace:: :ref:`Kubernetes Version Upgrade Distributed Cloud Orchestration Overview <the-kubernetes-distributed-cloud-update-orchestration-process>`
 .. |installing-a-subcloud-without-redfish-platform-management-service| replace:: :ref:`Install a Subcloud Without Redfish Platform Management Service <installing-a-subcloud-without-redfish-platform-management-service>`
 .. |configuration-for-specific-subclouds| replace:: :ref:`Configuration for Specific Subclouds <configuration-for-specific-subclouds>`
-.. |distributed-upgrade-orchestration-process-using-the-cli| replace:: :ref:`Distributed Upgrade Orchestration Process using the CLI <distributed-upgrade-orchestration-process-using-the-cli>`
+.. |distributed-software-deploy-orchestration-process-using-the-cli| replace:: :ref:`Distributed Software Deploy Orchestration Process using the CLI <distributed-software-deploy-orchestration-process-using-the-cli>`
 .. |prestage-a-subcloud-using-dcmanager-df756866163f| replace:: :ref:`Prestage a Subcloud <prestage-a-subcloud-using-dcmanager-df756866163f>`
 .. |upgrade-management-overview| replace:: :ref:`Upgrade Management Overview <upgrade-management-overview>`
 .. |reviewing-update-status-for-distributed-cloud-using-the-cli| replace:: :ref:`Review Update Status for Distributed Cloud Using the CLI <reviewing-update-status-for-distributed-cloud-using-the-cli>`
@@ -100,7 +100,6 @@
 .. |rehoming-a-subcloud| replace:: :ref:`Rehome a Subcloud <rehoming-a-subcloud>`
 .. |changing-the-admin-password-on-distributed-cloud| replace:: :ref:`Change the Admin Password on Distributed Cloud <changing-the-admin-password-on-distributed-cloud>`
 .. |synchronization-monitoring-and-control| replace:: :ref:`Synchronization Monitoring and Control <synchronization-monitoring-and-control>`
-.. |ochestration-strategy-using-subcloud-groups| replace:: :ref:`Orchestration Strategy Using Subcloud Groups <ochestration-strategy-using-subcloud-groups>`
 .. |configuring-kubernetes-update-orchestration-on-distributed-cloud| replace:: :ref:`Configure Kubernetes Version Upgrade Distributed Cloud Orchestration <configuring-kubernetes-update-orchestration-on-distributed-cloud>`
 .. |monitoring-subclouds-using-horizon| replace:: :ref:`Monitor Subclouds Using Horizon <monitoring-subclouds-using-horizon>`
 .. |overview-of-distributed-cloud-geo-redundancy| replace:: :ref:`Overview of Distributed Cloud GEO Redundancy <overview-of-distributed-cloud-geo-redundancy>`

doc/source/dist_cloud/kubernetes/abort-the-distributed-software-deploy-orchestration.rst

@@ -0,0 +1,21 @@
+
+.. hil1593180554641
+.. _abort-the-distributed-software-deploy-orchestration:
+
+===================================================
+Abort the Distributed Software Deploy Orchestration
+===================================================
+
+To abort the current software deploy orchestration operation, use the
+:command:`sw-deploy-strategy abort` command.
+
+.. note::
+
+    The :command:`dcmanager sw-deploy-strategy abort` command completes the
+    current sw-deploy stage before aborting, to prevent hosts from being left
+    in a locked state requiring manual intervention.
+
+.. code-block:: none
+
+    ~(keystone_admin)]$ dcmanager sw-deploy-strategy abort
+

doc/source/dist_cloud/kubernetes/aborting-the-distributed-upgrade-orchestration.rst

@@ -1,21 +0,0 @@
-
-.. hil1593180554641
-.. _aborting-the-distributed-upgrade-orchestration:
-
-==============================================
-Aborting the Distributed Upgrade Orchestration
-==============================================
-
-To abort the current upgrade orchestration operation, use the
-:command:`upgrade-strategy abort` command.
-
-.. note::
-
-    The :command:`dcmanager upgrade-strategy abort` command completes the
-    current upgrading stage before aborting, to prevent hosts from being left
-    in a locked state requiring manual intervention.
-
-.. code-block:: none
-
-    ~(keystone_admin)]$ dcmanager upgrade-strategy abort
-

doc/source/dist_cloud/kubernetes/applying-the-update-strategy-for-distributed-cloud.rst

@@ -18,6 +18,8 @@ To use the CLI, see :ref:`update-management-for-distributed-cloud`.
 
 Before you can apply the update strategy to the subclouds:
 
+-   Subcloud should be |prod-ver|/N-1
+
 -   Upload and apply one or more updates to the SystemController / central
     update repository.
 

doc/source/dist_cloud/kubernetes/create-a-firmware-update-orchestration-strategy-using-horizon-cfecdb67cef2.rst

@@ -82,7 +82,7 @@ You must be in the SystemController region. To change the mode, see
 
 .. rubric:: |result|
 
-Only subclouds in the Managed state and whose patching sync status is
+Only subclouds in the Managed state and whose firmware sync status is
 ``out-of-sync`` are added to the list. To change the firmware upgrade strategy
 settings, you must delete the current strategy and create a new one. You must
 confirm before applying the strategy. If the created strategy is older than 60

doc/source/dist_cloud/kubernetes/create-a-kubernetes-upgrade-orchestration-using-horizon-16742b62ffb2.rst

@@ -90,7 +90,7 @@ You can use the Horizon Web interface to check the alarm states:
 
 .. rubric:: |result|
 
-Only subclouds in the Managed state and whose patching sync status is
+Only subclouds in the Managed state and whose kubernetes sync status is
 ``out-of-sync`` are added to the list. To change the Kubernetes Upgrade
 strategy settings, you must delete the current strategy and create a new one.
 You must confirm before applying the strategy. If the strategy is older than 60

doc/source/dist_cloud/kubernetes/create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706.rst

@@ -7,15 +7,15 @@ Create a Software Deploy Orchestration using Horizon
 .. rubric:: |prereq|
 
 You must have completed the procedure in
-:ref:`distributed-upgrade-orchestration-process-using-the-cli`.
+:ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
 
 .. rubric:: |proc|
 
-#.  Review the upgrade status for the subclouds.
+#.  Review the software deploy status for the subclouds.
 
-    After the System Controller upgrade is completed, wait for 10 minutes for
+    After the System Controller software deploy/update is completed, wait for
-    the ``load_sync_status`` of all subclouds to be updated. To check the
+    40 seconds for the ``software_sync_status`` of all subclouds to be updated.
-    subclouds status:
+    To check the subclouds status:
 
     #. Select the **SystemController** region.
 
@@ -38,7 +38,7 @@ You must have completed the procedure in
           Software Deploy
 
        **Release**
-          Release name.
+          Release ID.
 
           This option is available when **Strategy Type** is set to "Software
           Deploy".
@@ -72,14 +72,14 @@ You must have completed the procedure in
           ``max_parallel_subclouds`` defined for each subcloud group will be
           used by default.
 
-    #. Adjust how the Upgrade on subclouds will be performed.
+    #. Adjust how the Software Deploy on subclouds will be performed.
 
     #. Save the new strategy.
 
-       Only subclouds in the Managed state and whose patching sync status is
+       Only subclouds in the Managed state and whose software sync status is
-       ``out-of-sync`` are added to the list. To change the Upgrade strategy
+       ``out-of-sync`` are added to the list. To change the Software Deploy
-       settings, you must delete the current strategy and create a new one.
+       strategy settings, you must delete the current strategy and create a new
-       Confirmation before applying strategy will be needed. If the created
+       one. Confirmation before applying strategy will be needed. If the
-       strategy is older than 60 minutes, a warning message will be display on
+       created strategy is older than 60 minutes, a warning message will be
-       this popup. The user can apply the strategy or verify if it is still
+       display on this popup. The user can apply the strategy or verify if it
-       valid.
+       is still valid.

doc/source/dist_cloud/kubernetes/creating-an-update-strategy-for-distributed-cloud-update-orchestration.rst

@@ -84,6 +84,11 @@ You must be in **SystemController** region. To change the region, see
 
         This option is available when **Strategy Type** is set to "Patch".
 
+    **Delete**
+        Delete the patch from the subclouds.
+
+        This option is available when **Strategy Type** is set to "Patch".
+
 #.  Adjust how nodes are updated on the subclouds.
 
     See :ref:`customizing-the-update-configuration-for-distributed-cloud-update-orchestration`.

doc/source/dist_cloud/kubernetes/distributed-software-deploy-orchestration-process-using-the-cli.rst

@@ -1,72 +1,67 @@
 .. pek1594745988225
-.. _distributed-upgrade-orchestration-process-using-the-cli:
+.. _distributed-software-deploy-orchestration-process-using-the-cli:
 
-=======================================================
+===============================================================
-Distributed Upgrade Orchestration Process using the CLI
+Distributed Software Deploy Orchestration Process using the CLI
-=======================================================
+===============================================================
 
-Distributed upgrade orchestration can be initiated after the System Controller
+Distributed software deploy orchestration can be initiated after the System
-has been successfully upgraded.
+Controller has been successfully updated (patch) or deployed.
 
 For more information on Prestaging Subcloud Orchestration see,
 :ref:`prestage-subcloud-orchestration-eb516473582f`.
 
+.. note::
+
+    This section is applicable to users that use the dcmanager software deploy
+    orchestration strategy to manage upgrades across subclouds.
+
+    Refer to |updates-doc| for more details.
+
 .. rubric:: |context|
 
-The user first creates a distributed upgrade orchestration strategy, or plan,
+The user first creates a distributed software deploy orchestration strategy, or
-for the automated upgrade procedure. This customizes the upgrade orchestration,
+plan, for the automated software deploy procedure. This customizes the software
-using parameters to specify:
+deploy orchestration, using parameters to specify:
 
 
 .. _distributed-upgrade-orchestration-process-using-the-cli-ul-eyw-fyr-31b:
 
--   whether to stop on failure of a subcloud upgrade or continue with the next
+-   whether to stop on failure of a subcloud update/upgrade or continue with
-    subcloud
+    the next subcloud
 
--   whether to upgrade hosts serially or in parallel
+-   whether to update/upgrade hosts serially or in parallel
 
 
-Based on these parameters, and the state of the subclouds, the upgrade
+Based on these parameters, and the state of the subclouds, the software deploy
-orchestration creates a number of stages for the overall upgrade strategy. All
+orchestration creates a number of stages for the overall sw-deploy strategy.
-the subclouds that are included in the same stage will be upgraded in parallel.
+All the subclouds that are included in the same stage will be updated/upgraded
+in parallel.
 
 .. rubric:: |prereq|
 
-Distributed upgrade orchestration can only be done on a system that meets the
+Distributed software deploy orchestration can only be done on a system that
-following conditions:
+meets the following conditions:
 
 .. _distributed-upgrade-orchestration-process-using-the-cli-ul-blp-gcx-ry:
 
--   The subclouds must use the Redfish platform management service if it is an
+-   All subclouds are clear of management-affecting alarms (with the exception
-    |AIO-SX| subcloud. The install values as well as `bmc_password`
+    of the alarm upgrade in progress).
-    for each |AIO-SX| subcloud must have already been saved in the system
-    controller database before the start of orchestrated subcloud upgrade.
-
-    .. note::
-        The following command is only required if the |AIO-SX| subcloud install
-        values and `bmc_password` have never been provided using
-        :command:`dcmanager CLI` command.
-
-    .. code-block:: none
-
-        ~(keystone_admin)]$ dcmanager subcloud update subcloud1 --install-values\
-        install-values.yaml --bmc-password <password>
-
-    For more information on :command:`install-values.yaml` file, see
-    :ref:`Installing a Subcloud Using Redfish Platform Management Service
-    <installing-a-subcloud-using-redfish-platform-management-service>`.
-
--   Duplex (|AIO-DX|/Standard) upgrades are supported, and they do not
-    require remote install using Redfish.
-
--   All subclouds are clear of management-affecting alarms (with the exception of the alarm upgrade
-    in progress).
 
 -   All hosts of all subclouds must be unlocked, enabled, and available.
 
--   No distributed upgrade orchestration strategy exists, to verify use the
+-   All subclouds should have been prestaged (``--for-sw-deploy``).
-    command :command:`dcmanager upgrade-strategy-show`. An upgrade cannot be
+
-    orchestrated while upgrade orchestration is in progress.
+    .. code-block:: none
+
+        ~(keystone_admin)]$ dcmanager prestage-strategy create --for-sw-deploy
+
+-   All the subclouds do not have any VIM strategy different from ``sw-deploy``
+    or in an invalid state.
+
+-   No distributed software deploy orchestration strategy exists, to verify use
+    the command :command:`dcmanager sw-deploy-strategy show`. An update/upgrade
+    cannot be orchestrated while software deploy orchestration is in progress.
 
 -   The size and format of the persistent filesystem, /opt/platform-backup, of
     each subcloud must be 30GiB (or larger) and ext4 respectively. From the shell
@@ -90,8 +85,9 @@ following conditions:
 
     :command:`sudo rm /opt/platform-backup/upgrade_data\*`
 
-You can configure an upgrade Distributed Cloud orchestration strategy using the
+You can configure a software deploy Distributed Cloud orchestration strategy
-dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
+using the dcmanager CLI or the Horizon web interface. If you prefer to use
+Horizon, see
 :ref:`create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706`.
 
 
@@ -99,12 +95,12 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
 
 .. _distributed-upgrade-orchestration-process-using-the-cli-steps-vcm-pq4-3mb:
 
-#.  Review the upgrade status for the subclouds.
+#.  Review the software status for the subclouds.
 
-    After the System Controller upgrade is completed, wait for 10 minutes for
+    After the System Controller upgrade/deploy is completed, wait for 40
-    the **load_sync_status** of all subclouds to be updated.
+    seconds for the **software_sync_status** of all subclouds to be updated.
 
-    To identify which subclouds are upgrade-current (in-sync), use the
+    To identify which subclouds are deploy-current (in-sync), use the
     :command:`subcloud list` command. For example:
 
     .. code-block:: none
@@ -120,9 +116,10 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
         +----+-----------+--------------+--------------------+-------------+
 
     .. note::
-        The subclouds are out-of-sync because the load-sync-status is out-of-sync.
+
-        All of the above subclouds are not upgrade-current and, therefore, need
+        The subclouds are out-of-sync because the software-sync-status is
-        to be upgraded.
+        out-of-sync. All of the above subclouds are not deploy-current and,
+        therefore, need to be upgraded/updated.
 
     To see synchronization details for a subcloud, use the following command:
 
@@ -152,25 +149,25 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
         | firmware_sync_status        | in-sync                      |
         | identity_sync_status        | in-sync                      |
         | kubernetes_sync_status      | in-sync                      |
-        | load_sync_status            | out-of-sync                  |
+        | load_sync_status            | not-available                |
-        | patching_sync_status        | in-sync                      |
+        | patching_sync_status        | not-available                |
+        | software_sync_status        | out-of-sync                  |
         | platform_sync_status        | in-sync                      |
         +-----------------------------+------------------------------+
 
-#.  To create an upgrade strategy, use the :command:`dcmanager upgrade-strategy create`
+#.  To create a sw-deploy strategy, use the :command:`dcmanager sw-deploy-strategy create <release_id>`
     command.
 
-    The upgrade strategy for a |prod-dc| system controls how upgrades are
+    The sw-deploy strategy for a |prod-dc| system controls how updates/upgrades
-    applied to subclouds.
+    are applied to subclouds.
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager upgrade-strategy create \
+        ~(keystone_admin)]$  dcmanager sw-deploy-strategy create \
         [--subcloud-apply-type <type>] \
         [–-max-parallel-subclouds <i>] \
         [–-stop-on-failure <level>] \
         [--group group] \
-        [--force] \
         [<subcloud>]
 
     where:
@@ -198,43 +195,40 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
 
     **group**
         Optionally pass the name or ID of a subcloud group to the
-        :command:`dcmanager upgrade-strategy create` command. This results in a
+        :command:`dcmanager sw-deploy-strategy create` command. This results in a
         strategy that is only applied to all subclouds in the specified group.
         The subcloud group values are used for subcloud apply type and max
         parallel subclouds parameters.
 
-    **force**
-        Upgrade both online and offline subclouds. Can be used for a single
-        subcloud, or a subcloud group.
-
     For example:
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager upgrade-strategy create
+        ~(keystone_admin)]$ dcmanager sw-deploy-strategy create
         +------------------------+----------------------------+
         | Field                  | Value                      |
         +------------------------+----------------------------+
-        | strategy type          | upgrade                    |
+        | strategy type          | sw-deploy                  |
         | subcloud apply type    | parallel                   |
         | max parallel subclouds | 2                          |
         | stop on failure        | False                      |
         | state                  | initial                    |
-        | created_at             | 2020-06-10T17:16:51.857207 |
+        | created_at             | 2024-11-06 12:56:17.111621 |
         | updated_at             | None                       |
         +------------------------+----------------------------+
 
-#.  To show the settings for the upgrade strategy, use the
+#.  To show the settings for the ``sw-deploy-strategy``, use the
-    :command:`dcmanager upgrade-strategy show` command.
+    :command:`dcmanager sw-deploy-strategy show` command.
 
     For example:
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager upgrade-strategy show
+        ~(keystone_admin)]$ dcmanager sw-deploy-strategy show
         +------------------------+----------------------------+
         | Field                  | Value                      |
         +------------------------+----------------------------+
+        | strategy type          | sw-deploy                  |
         | subcloud apply type    | parallel                   |
         | max parallel subclouds | 2                          |
         | stop on failure        | False                      |
@@ -248,34 +242,35 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
         be taken from the subcloud group if specified through the ``--group``
         parameter.
 
-#.  Review the upgrade strategy for the subclouds.
+#.  Review the sw-deploy strategy for the subclouds.
 
-    To show the subclouds that will be upgraded when the upgrade strategy is
+    To show the subclouds that will be upgraded when the sw-deploy strategy is
     applied, use the :command:`dcmanager strategy-step list` command. For
     example:
 
     .. code-block:: none
 
         ~(keystone_admin)]$ dcmanager strategy-step list
-        +------------------+-------+---------+---------+------------+-------------+
+        +------------------+--------+---------+---------+------------+-------------+
-        | cloud            | stage | state   | details | started_at | finished_at |
+        | cloud            | stage  | state   | details | started_at | finished_at |
-        +------------------+-------+---------+---------+------------+-------------+
+        +------------------+--------+---------+---------+------------+-------------+
-        | subcloud-1       |     1 | initial |         | None       | None        |
+        | subcloud-1       | 1      | initial |         | None       | None        |
-        | subcloud-4       |     1 | initial |         | None       | None        |
+        | subcloud-4       | 1      | initial |         | None       | None        |
-        | subcloud-5       |     2 | initial |         | None       | None        |
+        | subcloud-5       | 2      | initial |         | None       | None        |
-        | subcloud-6       |     2 | initial |         | None       | None        |
+        | subcloud-6       | 2      | initial |         | None       | None        |
-        +------------------+-------+---------+---------+------------+-------------+
+        +------------------+--------+---------+---------+------------+-------------+
 
     .. note::
-        All the subclouds that are included in the same stage will be upgraded
+
+        All the subclouds that are included in the same stage will be deployed
         in parallel.
 
-#.  To apply the upgrade strategy, use the :command:`dcmanager upgrade-strategy apply`
+#.  To apply the software deploy strategy, use the :command:`dcmanager sw-deploy-strategy apply`
     command.
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager upgrade-strategy apply
+        ~(keystone_admin)]$ dcmanager sw-deploy-strategy apply
         +------------------------+----------------------------+
         | Field                  | Value                      |
         +------------------------+----------------------------+
@@ -287,13 +282,6 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
         | updated_at             | 2020-02-02T14:42:19.376688 |
         +------------------------+----------------------------+
 
-    .. warning::
-        Do not log in to the subcloud using the sysadmin account during an upgrade
-        procedure. During an upgrade, the subcloud password is reset to the default
-        value and is subsequently resynced, and any login attempt during the
-        upgrade will fail. Also, consecutive unsuccessful login attempts may lock
-        your account.
-
 #.  To show the step currently being performed on each of the subclouds, use
     the :command:`dcmanager strategy-step list` command.
 
@@ -302,14 +290,14 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
     .. code-block:: none
 
         ~(keystone_admin)]$ dcmanager strategy-step list
-        +------------------+-------+-----------------------+-------------------+----------------------------+----------------------------+
+        +------------------+--------+-----------------------+-------------------+----------------------------+----------------------------+
-        | cloud            | stage | state                 | details           | started_at                 | finished_at                |
+        | cloud            | stage  | state                 | details           | started_at                 | finished_at                |
-        +------------------+-------+-----------------------+-------------------+----------------------------+----------------------------+
+        +------------------+--------+-----------------------+-------------------+----------------------------+----------------------------+
-        | subcloud-1       |     1 | complete              |                   | 2021-06-11 14:12:12.262001 | 2021-06-11 14:15:52.450908 |
+        | subcloud-1       | 3      | complete              |                   | 2024-11-06 12:57:20.342429 | 2024-11-06 12:57:41.054664 |
-        | subcloud-4       |     1 | activating upgrade    |                   | 2021-06-11 14:16:02.457588 | None                       |
+        | subcloud-4       | 2      | apply VIM sw-deploy   |                   | 2024-11-06 12:57:20.342429 | None                       |
-        | subcloud-5       |     2 | initial               |                   | None                       | None                       |
+        | subcloud-5       | 1      | initial               |                   | None                       | None                       |
-        | subcloud-6       |     2 | initial               |                   | None                       | None                       |
+        | subcloud-6       | 1      | initial               |                   | None                       | None                       |
-        +------------------+-------+-------------+-----------------------------+----------------------------+----------------------------+
+        +------------------+--------+-------------+-----------------------------+----------------------------+----------------------------+
 
 #.  To show the step currently being performed on a subcloud, use the
     :command:`dcmanager strategy-step show` <subcloud> command.
@@ -318,13 +306,13 @@ dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
 
         ~(keystone_admin)]$ dcmanager strategy-step show <subcloud>
 
-#.  When all the subclouds within the distributed upgrade orchestration indicate
+#.  When all the subclouds within the distributed software deploy orchestration indicate
-    they have entered the complete state, delete the upgrade strategy, using
+    they have entered the complete state, delete the sw-deploy strategy, using
-    the :command:`dcmanager upgrade-strategy delete` command.
+    the :command:`dcmanager sw-deploy-strategy delete` command.
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager upgrade-strategy delete
+        ~(keystone_admin)]$ dcmanager sw-deploy-strategy delete
         +------------------------+----------------------------+
         | Field                  | Value                      |
         +------------------------+----------------------------+

doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst

@@ -87,7 +87,7 @@ Manage Subcloud Groups
     create-subcloud-groups-using-the-horizon-web-interface-69d357303531
     edit-subcloud-groups-85232c3a7d33
     delete-subcloud-groups-22a7c65e66d7
-    ochestration-strategy-using-subcloud-groups
+    orchestration-strategy-using-subcloud-groups
 
 
 --------------------------------------------------------
@@ -179,10 +179,10 @@ Upgrade Orchestration for Distributed Cloud SubClouds
 .. toctree::
     :maxdepth: 1
 
-    distributed-upgrade-orchestration-process-using-the-cli
+    distributed-software-deploy-orchestration-process-using-the-cli
     create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706
     apply-the-software-deploy-strategy-using-horizon-d0aab18cc724
-    aborting-the-distributed-upgrade-orchestration
+    abort-the-distributed-software-deploy-orchestration
     configuration-for-specific-subclouds
     robust-error-handling-during-an-orchestrated-upgrade
     failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud

doc/source/dist_cloud/kubernetes/managing-subcloud-groups.rst

@@ -42,7 +42,7 @@ or firmware updates, see:
 
 .. xbooklink For more information see, :ref:`Distributed
     Upgrade Orchestration Process Using the CLI
-    <distributed-upgrade-orchestration-process-using-the-cli>`.
+    <distributed-software-deploy-orchestration-process-using-the-cli>`.
 
 -   To create an update (patch) orchestration strategy use the
     :command:`dcmanager patch-strategy create` command.
@@ -60,8 +60,6 @@ or firmware updates, see:
 
 .. seealso::
 
-    :ref:`Creating Subcloud Groups <creating-subcloud-groups>`
+    :ref:`creating-subcloud-groups`
-
-    :ref:`Orchestration Strategy Using Subcloud Groups <ochestration-strategy-using-subcloud-groups>`
-
 
+    :ref:`orchestration-strategy-using-subcloud-groups`

doc/source/dist_cloud/kubernetes/orchestration-commands-for-dcmanager-4947f9fb9588.rst

@@ -63,8 +63,9 @@ status.
         | identity_sync_status        | in-sync                    |
         | kubernetes_sync_status      | in-sync                    |
         | kube-rootca_sync_status     | in-sync                    |
-        | load_sync_status            | in-sync                    |
+        | load_sync_status            | not-available              |
-        | patching_sync_status        | in-sync                    |
+        | patching_sync_status        | not-available              |
+        | software_sync_status        | out-of-sync                |
         | platform_sync_status        | in-sync                    |
         +-----------------------------+----------------------------+
 
@@ -85,7 +86,7 @@ status.
         [--subcloud-apply-type \{parallel,serial}]
         [--max-parallel-subclouds MAX_PARALLEL_SUBCLOUDS]
         [--stop-on-failure]
-        [--force] [--group GROUP]
+        [--group GROUP]
         [--subject SUBJECT]
         [--expiry-date EXPIRY_DATE]
         [--cert-file CERT_FILE]
@@ -105,8 +106,6 @@ status.
             Maximum number of parallel subclouds.
         --stop-on-failure
             Do not update any additional subclouds after a failure.
-        --force
-            Disregard subcloud availability status, intended for some upgrade recovery scenarios. Subcloud name can be specified.
         --group GROUP
             Name or ID of subcloud group to update.
         --subject 'C=CA ST=ON L=OTT O=WR OU=STX CN=OTHER'
@@ -116,12 +115,6 @@ status.
         --cert-file CERT_FILE
             Path to a certificate to upload.
 
-A subcloud can have its Kubernetes Root |CA| updated by the orchestrator even
-if it is 'in-sync' by using the :command:`--force` command.
-
-The :command:`--force` command can be used to orchestrate all subclouds, or
-used with other arguments to orchestrate just one subcloud or subcloud group.
-
 .. rubric:: |eg|
 
 This is an example of how to orchestrate a new certificate for all subclouds,
@@ -131,7 +124,7 @@ including those that are in-sync that will expire in one year.
 
     .. code-block::
 
-        ~(keystone_admin)]$ dcmanager kube-rootca-update-strategy create --force --expiry-date YYYY-MM-DD
+        ~(keystone_admin)]$ dcmanager kube-rootca-update-strategy create --expiry-date YYYY-MM-DD
 
         +-----------------------------+----------------------------+
         | Field                       | Value                      |
@@ -142,7 +135,7 @@ including those that are in-sync that will expire in one year.
         | stop on failure             | False                      |
         | state                       | initial                    |
         | created_at                  | 2021-10-26T14:35:50.675988 |
-        | updated_at                  |  None                      |
+        | updated_at                  | None                       |
         +-----------------------------+----------------------------+
 
 #.  Verify that the strategy will orchestrate the subcloud(s).
@@ -151,11 +144,11 @@ including those that are in-sync that will expire in one year.
 
         ~(keystone_admin)]$ dcmanager strategy-step list
 
-        +-----------+-------+---------+---------+------------+-------------+
+        +-----------+--------+---------+---------+------------+-------------+
-        | cloud     | stage | state   | details | started_at | finished_at |
+        | cloud     | stage  | state   | details | started_at | finished_at |
-        +-----------+-------+---------+---------+------------+-------------+
+        +-----------+--------+---------+---------+------------+-------------+
-        | subcloud1 | 2     | initial |         | None       | None        |
+        | subcloud1 | 1      | initial |         | None       | None        |
-        +-----------+-------+---------+---------+------------+-------------+
+        +-----------+--------+---------+---------+------------+-------------+
 
 #.  Apply the strategy.
 
@@ -208,7 +201,7 @@ including those that are in-sync that will expire in one year.
         | subcloud1 | 2     | applying vim kube rootca update strategy | apply phase is 0% complete | 2021-10-26 14:37:46.404736 | None        |
         +-----------+-------+------------------------------------------+----------------------------+----------------------------+-------------+
 
-#.  Wait for the strategy to complete.  If there are failures, the
+#.  Wait for the strategy to complete. If there are failures, the
     :command:`show` command in the previous step indicates where the failure
     occurred.
 

doc/source/dist_cloud/kubernetes/orchestration-strategy-using-subcloud-groups.rst

@@ -1,6 +1,5 @@
-
 .. afr1600186951848
-.. _ochestration-strategy-using-subcloud-groups:
+.. _orchestration-strategy-using-subcloud-groups:
 
 ============================================
 Orchestration Strategy Using Subcloud Groups
@@ -22,6 +21,4 @@ subcloud groups, is the order they are processed by orchestration.
 
 #.  Subclouds from different groups will never be included in the same stage of
     the strategy to ensure they are not upgraded, updated (patched) at the
-    same time.
+    same time.
-
-

doc/source/dist_cloud/kubernetes/reviewing-update-status-for-distributed-cloud-using-the-cli.rst

@@ -24,20 +24,19 @@ Distributed Cloud Using Horizon
 
     For example:
 
-    .. parsed-literal::
+    .. code-block:: none
 
-        ~(keystone_admin)]$ sw-patch --os-region-name SystemController query
+        ~(keystone_admin)]$ software --os-region-name SystemController list
-        Patch ID              RR  Release   Patch State
+        +-------------------+-------+----------+
-        ===================   ==  =======   ===========
+        | Release           | RR    |  State   |
-        wrcp_nn.nn_PATCH_0001  N   nn.nn     Applied
+        +-------------------+-------+----------+
-        wrcp_nn.nn_PATCH_0002  N   nn.nn     Applied
+        | starlingx-24.09.0 | True  | deployed |
-        wrcp_nn.nn_PATCH_0003  N   nn.nn     Partial
+        | starlingx-24.09.1 | False | deployed |
-        wrcp_nn.nn_PATCH_0004  N   nn.nn     Available
+        +-------------------+-------+----------+
-        wrcp_nn.nn_PATCH_0005  N   nn.nn     Available
 
-    The **Patch State** column indicates whether the Patch is available,
+    The **State** column indicates whether the release is available, or
-    partially-applied or applied. **Applied** indicates that the update has
+    deployed. **deployed** indicates that the release has been installed on all
-    been installed on all hosts of the cloud (SystemController in this case).
+    hosts of the cloud (SystemController in this case).
 
 -   To identify which subclouds are update-current (**in-sync**), use the
 
@@ -50,14 +49,13 @@ Distributed Cloud Using Horizon
         |  1 | subcloud1 | managed      | online             | in-sync     |
         |  2 | subcloud2 | managed      | online             | in-sync     |
         |  3 | subcloud3 | managed      | online             | out-of-sync |
-        |  4 | subcloud4 | managed      | offline            | unknown     |
         +----+-----------+--------------+--------------------+-------------+
 
     .. note::
 
         The **sync** status is the rolled up sync status of
         **platform-sync-status**, **identity-sync-status**, and
-        **patching-sync-status**.
+        **software-sync-status**.
 
 -   To see synchronization details for a subcloud:
 
@@ -85,7 +83,8 @@ Distributed Cloud Using Horizon
         | updated_at                  | 2020-07-17 12:36:28.815655 |
         | dc-cert_sync_status         | in-sync                    |
         | identity_sync_status        | in-sync                    |
-        | load_sync_status            | in-sync                    |
+        | load_sync_status            | not-available              |
-        | patching_sync_status        | in-sync                    |
+        | patching_sync_status        | not-available              |
+        | software_sync_status        | in-sync                    |
         | platform_sync_status        | in-sync                    |
         +-----------------------------+----------------------------+

doc/source/dist_cloud/kubernetes/robust-error-handling-during-an-orchestrated-upgrade.rst

@@ -29,9 +29,8 @@ If a failure occurs, use the following general steps:
 #.  Address the cause of the failure. For more information, see
     :ref:`failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud`.
 
-#.  Retry the orchestrated upgrade. For more information, see :ref:`Distributed
+#.  Retry the orchestrated upgrade. For more information, see
-    Upgrade Orchestration Process Using the CLI
+    :ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
-    <distributed-upgrade-orchestration-process-using-the-cli>`.
 
 .. note::
     Orchestrated upgrade can be retried for a group of failed subclouds that

doc/source/dist_cloud/kubernetes/update-management-for-distributed-cloud.rst

@@ -21,7 +21,7 @@ the Central Cloud.
 
     Any updates that were applied to the Central Cloud prior to running
     :command:`ansible bootstrap playbook`, including updates incorporated in
-    the installation ISO file and updates installed using :command:`sw-patch`
+    the installation ISO file and updates installed using :command:`software`
     commands, must be uploaded to the System Controller. This ensures that the
     updates are in the central update repository and the subclouds can be
     updated with them.

doc/source/dist_cloud/kubernetes/update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli.rst

@@ -3,7 +3,7 @@
 .. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli:
 
 ===============================================
-Update Orchestration of Subclouds Using the CLI
+Update Orchestration of Subclouds using the CLI
 ===============================================
 
 For |prod-dc| update orchestration, you can use the :command:`dcmanager`
@@ -22,11 +22,11 @@ To use the Horizon Web interface instead, see
 
     Before you can use |prod-dc| update orchestration, you must upload and
     apply one or more updates to the SystemController / central update
-    repository, and then update the RegionOne. For more information, see
+    repository, and then update the RegionOne, the subcloud should not support
+    the API software. For more information, see
     :ref:`uploading-and-applying-updates-to-systemcontroller-using-the-cli`.
 
 
-
 .. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli-section-N10087-N10029-N10001:
 
 -----------------------
@@ -34,8 +34,10 @@ Patch Strategy Settings
 -----------------------
 
 The update strategy for a |prod-dc| system controls how updates are applied to
-the subclouds. The following settings are
+the subclouds. The following settings are available:
-available:
+
+**patch id**
+    The ID of the patch to be applied.
 
 **subcloud apply type**
     parallel or serial — determines whether the subclouds are updated in
@@ -60,14 +62,17 @@ available:
     the patch strategy will only upload the necessary patches to the subclouds,
     without executing the other steps (apply, install, reboot, etc.).
 
+**delete**
+    the patch will be deleted. Could not be used with ``--upload-only``.
 
 .. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli-ul-blq-nmx-fdb:
 
--   To create a update strategy, use the :command:`patch-strategy create` command.
+-   To create an update strategy, use the :command:`patch-strategy create <patch_id>`
+    command.
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager patch-strategy create \
+        ~(keystone_admin)]$ dcmanager patch-strategy create <patch_id> \
         [--subcloud-apply-type <type>] \
         [–-max-parallel-subclouds <i>] \
         [–-stop-on-failure <level>] \
@@ -80,7 +85,7 @@ available:
 
     .. code-block:: none
 
-        ~(keystone_admin)]$ dcmanager patch-strategy create --group 10
+        ~(keystone_admin)]$ dcmanager patch-strategy create <patch_id> --group 10
         +------------------------+----------------------------+
         | Field                  | Value                      |
         +------------------------+----------------------------+
@@ -100,7 +105,7 @@ available:
         subcloud group values are used for subcloud apply type and max parallel
         subclouds parameters.
 
-    To only upload the necessary patches to the subclouds, without executing
+    To only upload the necessary patch to the subclouds, without executing
     the other steps (apply, install, reboot, etc.), use the
     :command:`patch-strategy create --upload-only` command.
 
@@ -131,6 +136,25 @@ available:
         skips directly to the ``complete`` state once the patches are uploaded
         to the subclouds.
 
+    To delete the patch instead of install, use the :command:`patch-strategy create --delete`
+    command.
+
+    .. code-block:: none
+
+         ~(keystone_admin)]$ dcmanager patch-strategy create --delete
+        +------------------------+----------------------------+
+        | Field                  | Value                      |
+        +------------------------+----------------------------+
+        | strategy type          | patch                      |
+        | subcloud apply type    | None                       |
+        | max parallel subclouds | None                       |
+        | stop on failure        | False                      |
+        | upload only            | False                      |
+        | state                  | initial                    |
+        | created_at             | 2023-03-08T13:58:50.130629 |
+        | updated_at             | None                       |
+        +------------------------+----------------------------+
+
 -   To show the settings for the update strategy, use the
     :command:`patch-strategy show` command.
 

doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst

@@ -28,7 +28,7 @@ follows:
     System Controller. See :ref:`upgrading-the-systemcontroller-using-the-cli`.
 
 #.  Use |prod-dc| Upgrade Orchestration to upgrade the subclouds. See
-    :ref:`distributed-upgrade-orchestration-process-using-the-cli`.
+    :ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
 
 #.  To handle errors during an orchestrated upgrade, see :ref:`robust-error-handling-during-an-orchestrated-upgrade`.
 

doc/source/updates/kubernetes/manual-host-software-deployment-ee17ec6f71a4.rst

@@ -11,6 +11,12 @@ Manual Host Software Deployment
 new patch release or a new major release using a manual procedure of
 step-by-step host-by-host commands.
 
+
+.. note::
+
+    This section is applicable to users that DO NOT use the dcmanager software
+    deploy orchestration strategy to manage upgrades across subclouds.
+
 .. rubric:: |context|
 
 This procedure describes upversioning to either a new patch release (in-service

doc/source/updates/kubernetes/orchestrated-deployment-host-software-deployment-d234754c7d20.rst

@@ -26,7 +26,7 @@ Software deployment Orchestration supports all standalone configurations:
     Orchestrating the software deployment of subclouds in a |DC| system is
     different from orchestrating the software deployment of standalone |prod|
     configurations. See
-    :ref:`distributed-upgrade-orchestration-process-using-the-cli`.
+    :ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
 
 Software deployment orchestration automatically iterates through all the hosts
 and deploys the new software load on each host: first the controller hosts,