starlingx/docs
Code Issues Proposed changes

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

Browse Source
This commit is contained in:
Zuul 2024-12-11 19:17:30 +00:00 committed by Gerrit Code Review
commit de773c32a1
20 changed files with 216 additions and 206 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/source/_vendor/rl-strings.txt
View File

@ -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>`

21
doc/source/dist_cloud/kubernetes/abort-the-distributed-software-deploy-orchestration.rst Normal file
View File

@ -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

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

@ -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

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

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

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

@ -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

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

@ -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

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

@ -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
the ``load_sync_status`` of all subclouds to be updated. To check the
subclouds status:
After the System Controller software deploy/update is completed, wait for
40 seconds for the ``software_sync_status`` of all subclouds to be updated.
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
``out-of-sync`` are added to the list. To change the Upgrade strategy
settings, you must delete the current strategy and create a new one.
Confirmation before applying strategy will be needed. If the created
strategy is older than 60 minutes, a warning message will be display on
this popup. The user can apply the strategy or verify if it is still
valid.
Only subclouds in the Managed state and whose software sync status is
``out-of-sync`` are added to the list. To change the Software Deploy
strategy settings, you must delete the current strategy and create a new
one. Confirmation before applying strategy will be needed. If the
created strategy is older than 60 minutes, a warning message will be
display on this popup. The user can apply the strategy or verify if it
is still valid.

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

@ -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`.

182
doc/source/dist_cloud/kubernetes/distributed-upgrade-orchestration-process-using-the-cli.rst → doc/source/dist_cloud/kubernetes/distributed-software-deploy-orchestration-process-using-the-cli.rst
View File

@ -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
has been successfully upgraded.
Distributed software deploy orchestration can be initiated after the System
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,
for the automated upgrade procedure. This customizes the upgrade orchestration,
using parameters to specify:
The user first creates a distributed software deploy orchestration strategy, or
plan, for the automated software deploy procedure. This customizes the software
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
subcloud
- whether to stop on failure of a subcloud update/upgrade or continue with
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
orchestration creates a number of stages for the overall upgrade strategy. All
the subclouds that are included in the same stage will be upgraded in parallel.
Based on these parameters, and the state of the subclouds, the software deploy
orchestration creates a number of stages for the overall sw-deploy strategy.
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
following conditions:
Distributed software deploy orchestration can only be done on a system that
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
|AIO-SX| subcloud. The install values as well as `bmc_password`
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 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
command :command:`dcmanager upgrade-strategy-show`. An upgrade cannot be
orchestrated while upgrade orchestration is in progress.
- All subclouds should have been prestaged (``--for-sw-deploy``).
.. 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
dcmanager CLI or the Horizon web interface. If you prefer to use Horizon, see
You can configure a software deploy Distributed Cloud orchestration strategy
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
the **load_sync_status** of all subclouds to be updated.
After the System Controller upgrade/deploy is completed, wait for 40
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
to be upgraded.
The subclouds are out-of-sync because the software-sync-status is
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 |
| patching_sync_status | in-sync |
| load_sync_status | not-available |
| 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
applied to subclouds.
The sw-deploy strategy for a |prod-dc| system controls how updates/upgrades
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
:command:`dcmanager upgrade-strategy show` command.
#. To show the settings for the ``sw-deploy-strategy``, use the
: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 |
+------------------+-------+---------+---------+------------+-------------+
+------------------+--------+---------+---------+------------+-------------+
| subcloud-1 | 1 | initial | | None | None |
| subcloud-4 | 1 | initial | | None | None |
| subcloud-5 | 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 |
+------------------+-------+-----------------------+-------------------+----------------------------+----------------------------+
| subcloud-1 | 1 | complete | | 2021-06-11 14:12:12.262001 | 2021-06-11 14:15:52.450908 |
| subcloud-4 | 1 | activating upgrade | | 2021-06-11 14:16:02.457588 | None |
| subcloud-5 | 2 | initial | | None | None |
| subcloud-6 | 2 | initial | | None | None |
+------------------+-------+-------------+-----------------------------+----------------------------+----------------------------+
+------------------+--------+-----------------------+-------------------+----------------------------+----------------------------+
| subcloud-1 | 3 | complete | | 2024-11-06 12:57:20.342429 | 2024-11-06 12:57:41.054664 |
| subcloud-4 | 2 | apply VIM sw-deploy | | 2024-11-06 12:57:20.342429 | None |
| subcloud-5 | 1 | 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
they have entered the complete state, delete the upgrade strategy, using
the :command:`dcmanager upgrade-strategy delete` command.
#. When all the subclouds within the distributed software deploy orchestration indicate
they have entered the complete state, delete the sw-deploy strategy, using
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 |
+------------------------+----------------------------+

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

@ -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

8
doc/source/dist_cloud/kubernetes/managing-subcloud-groups.rst
View File

@ -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:`Orchestration Strategy Using Subcloud Groups <ochestration-strategy-using-subcloud-groups>`
:ref:`creating-subcloud-groups`
:ref:`orchestration-strategy-using-subcloud-groups`

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

@ -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 |
| patching_sync_status | in-sync |
| load_sync_status | not-available |
| 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 |
@ -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 |
+-----------+-------+---------+---------+------------+-------------+
| subcloud1 | 2 | initial | | None | None |
+-----------+-------+---------+---------+------------+-------------+
+-----------+--------+---------+---------+------------+-------------+
| subcloud1 | 1 | initial | | None | None |
+-----------+--------+---------+---------+------------+-------------+
#. Apply the strategy.

5
doc/source/dist_cloud/kubernetes/ochestration-strategy-using-subcloud-groups.rst → doc/source/dist_cloud/kubernetes/orchestration-strategy-using-subcloud-groups.rst
View File

@ -1,6 +1,5 @@
.. afr1600186951848
.. _ochestration-strategy-using-subcloud-groups:
.. _orchestration-strategy-using-subcloud-groups:
============================================
Orchestration Strategy Using Subcloud Groups
@ -23,5 +22,3 @@ 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.

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

@ -24,20 +24,19 @@ Distributed Cloud Using Horizon
For example:
.. parsed-literal::
.. code-block:: none
~(keystone_admin)]$ sw-patch --os-region-name SystemController query
Patch ID RR Release Patch State
=================== == ======= ===========
wrcp_nn.nn_PATCH_0001 N nn.nn Applied
wrcp_nn.nn_PATCH_0002 N nn.nn Applied
wrcp_nn.nn_PATCH_0003 N nn.nn Partial
wrcp_nn.nn_PATCH_0004 N nn.nn Available
wrcp_nn.nn_PATCH_0005 N nn.nn Available
~(keystone_admin)]$ software --os-region-name SystemController list
+-------------------+-------+----------+
| Release | RR | State |
+-------------------+-------+----------+
| starlingx-24.09.0 | True | deployed |
| starlingx-24.09.1 | False | deployed |
+-------------------+-------+----------+
The **Patch State** column indicates whether the Patch is available,
partially-applied or applied. **Applied** indicates that the update has
been installed on all hosts of the cloud (SystemController in this case).
The **State** column indicates whether the release is available, or
deployed. **deployed** indicates that the release has been installed on all
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 |
| patching_sync_status | in-sync |
| load_sync_status | not-available |
| patching_sync_status | not-available |
| software_sync_status | in-sync |
| platform_sync_status | in-sync |
+-----------------------------+----------------------------+

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

@ -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
Upgrade Orchestration Process Using the CLI
<distributed-upgrade-orchestration-process-using-the-cli>`.
#. Retry the orchestrated upgrade. For more information, see
:ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
.. note::
Orchestrated upgrade can be retried for a group of failed subclouds that

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

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

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

@ -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
available:
the subclouds. The following settings are 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.

2
doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst
View File

@ -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`.

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

@ -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

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

@ -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,