Merge "Upgrade Support doc update (r10.1)"
This commit is contained in:
commit
de773c32a1
@ -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>`
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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`.
|
||||
|
@ -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 |
|
||||
+------------------+-------+---------+---------+------------+-------------+
|
||||
+------------------+--------+---------+---------+------------+-------------+
|
||||
| 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 |
|
||||
+------------------+-------+-------------+-----------------------------+----------------------------+----------------------------+
|
||||
+------------------+--------+-----------------------+-------------------+----------------------------+----------------------------+
|
||||
| cloud | stage | state | details | started_at | finished_at |
|
||||
+------------------+--------+-----------------------+-------------------+----------------------------+----------------------------+
|
||||
| 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 |
|
||||
+------------------------+----------------------------+
|
@ -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
|
||||
|
@ -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`
|
||||
|
@ -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 |
|
||||
@ -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 |
|
||||
+-----------+-------+---------+---------+------------+-------------+
|
||||
| subcloud1 | 2 | initial | | None | None |
|
||||
+-----------+-------+---------+---------+------------+-------------+
|
||||
+-----------+--------+---------+---------+------------+-------------+
|
||||
| cloud | stage | state | details | started_at | finished_at |
|
||||
+-----------+--------+---------+---------+------------+-------------+
|
||||
| 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.
|
||||
|
||||
|
@ -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.
|
@ -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 |
|
||||
+-----------------------------+----------------------------+
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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`.
|
||||
|
||||
|
@ -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
|
||||
|
@ -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,
|
||||
|
Loading…
Reference in New Issue
Block a user