starlingx/docs
Code Issues Proposed changes

Distributed Cloud review updates/upgrades - draft (r10,dsR10)

Browse Source 
Fix updates and upgrades in distributed cloud guide
Review of the Distributed Cloud Guide to adjust to USM
Fix merge conflict https://review.opendev.org/c/starlingx/docs/+/937086
Fix merge conflict with https://review.opendev.org/c/starlingx/docs/+/937352
Created Horizon Section for Orchestrate Subcloud Prestage

Change-Id: I8b288e35ec76fcbc11ccbe7715aefff70722094d
Signed-off-by: Elisamara Aoki Gonçalves <elisamaraaoki.goncalves@windriver.com>
(cherry picked from commit 46630063f40ebeeb5a03fd10441ed825660bae7e)
This commit is contained in:
Elisamara Aoki Gonçalves 2024-12-13 14:07:55 +00:00
parent 5092c0e0e4
commit 371b5585d0
64 changed files with 1327 additions and 2798 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/_includes/review-software-release-status-for-distributed-cloud-using-the-cli.rest Normal file
View File

@ -0,0 +1,2 @@
.. status-update-table-begin
.. status-update-table-end

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

@ -37,61 +37,48 @@
.. |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>`
.. |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>`
.. |subclouds-previous-release-management-5e986615cb4b| replace:: :ref:`Subclouds Previous Release Management <subclouds-previous-release-management-5e986615cb4b>`
.. |delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd| replace:: :ref:`Delete Subcloud Backup Data Using DCManager CLI <delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd>`
.. |customizing-the-update-configuration-for-distributed-cloud-update-orchestration| replace:: :ref:`Customize the Update Configuration for Distributed Cloud Update Orchestration <customizing-the-update-configuration-for-distributed-cloud-update-orchestration>`
.. |subcloud-geo-redundancy-error-root-cause-correction-action-43449d658aae| replace:: :ref:`Subcloud GEO Redundancy Error Root Cause and Correction Action <subcloud-geo-redundancy-error-root-cause-correction-action-43449d658aae>`
.. |prestage-subcloud-orchestration-eb516473582f| replace:: :ref:`Prestage Subcloud Orchestration <prestage-subcloud-orchestration-eb516473582f>`
.. |orchestrate-subcloud-prestage-using-the-cli-eb516473582f| replace:: :ref:`Orchestrate Subcloud Prestage Using the CLI <orchestrate-subcloud-prestage-using-the-cli-eb516473582f>`
.. |orchestration-commands-for-dcmanager-4947f9fb9588| replace:: :ref:`Kubernetes Root CA Certificate Update for Distributed Cloud Orchestration <orchestration-commands-for-dcmanager-4947f9fb9588>`
.. |update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli| replace:: :ref:`Update Orchestration of Subclouds Using the CLI <update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli>`
.. |managing-ldap-linux-user-accounts-on-the-system-controller| replace:: :ref:`Managing LDAP Linux User Accounts on the System Controller <managing-ldap-linux-user-accounts-on-the-system-controller>`
.. |shared-configurations| replace:: :ref:`Shared Configurations <shared-configurations>`
.. |create-a-kubernetes-upgrade-orchestration-using-horizon-16742b62ffb2| replace:: :ref:`Create a Kubernetes Upgrade Orchestration using Horizon <create-a-kubernetes-upgrade-orchestration-using-horizon-16742b62ffb2>`
.. |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-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>`
.. |robust-error-handling-during-an-orchestrated-upgrade| replace:: :ref:`Error Handling During An Orchestrated Upgrade <robust-error-handling-during-an-orchestrated-upgrade>`
.. |uploading-and-applying-updates-to-systemcontroller-using-horizon| replace:: :ref:`Upload and Apply Updates to SystemController Using Horizon <uploading-and-applying-updates-to-systemcontroller-using-horizon>`
.. |creating-subcloud-groups| replace:: :ref:`Create Subcloud Groups <creating-subcloud-groups>`
.. |update-orchestration-of-central-clouds-regionone-and-subclouds| replace:: :ref:`Update Orchestration of Subclouds <update-orchestration-of-central-clouds-regionone-and-subclouds>`
.. |review-software-release-status-for-distributed-cloud-using-the-cli| replace:: :ref:`Review Software Release Status for Distributed Cloud Using the CLI <review-software-release-status-for-distributed-cloud-using-the-cli>`
.. |deploy-software-releases-using-the-horizon-dashboard-eea2f49efc2c| replace:: :ref:`Deploy Software Releases Using the Horizon Dashboard <deploy-software-releases-using-the-horizon-dashboard-eea2f49efc2c>`
.. |upload-software-releases-using-the-horizon-dashboard-67b418278e55| replace:: :ref:`Upload Software Releases Using the Horizon Dashboard <upload-software-releases-using-the-horizon-dashboard-67b418278e55>`
.. |create-edit-and-delete-subcloud-groups-using-the-cli| replace:: :ref:`Create Subcloud Groups <create-edit-and-delete-subcloud-groups-using-the-cli>`
.. |configure-distributed-cloud-system-controller-geo-redundancy-e3a31d6bf662| replace:: :ref:`Configure Distributed Cloud System Controller GEO Redundancy <configure-distributed-cloud-system-controller-geo-redundancy-e3a31d6bf662>`
.. |managing-subcloud-groups| replace:: :ref:`Manage Subcloud Groups <managing-subcloud-groups>`
.. |create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706| replace:: :ref:`Create an Upgrade Orchestration using Horizon <create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706>`
.. |create-subcloud-groups-using-the-horizon-web-interface-69d357303531| replace:: :ref:`Create Subcloud Groups Using the Horizon Web Interface <create-subcloud-groups-using-the-horizon-web-interface-69d357303531>`
.. |switching-to-a-subcloud-from-the-system-controller| replace:: :ref:`Switch to a Subcloud from the System Controller <switching-to-a-subcloud-from-the-system-controller>`
.. |update-management-for-distributed-cloud| replace:: :ref:`Update Management for Distributed Cloud <update-management-for-distributed-cloud>`
.. |apply-the-software-deploy-strategy-using-horizon-d0aab18cc724| replace:: :ref:`Apply the Software Deploy using Horizon <apply-the-software-deploy-strategy-using-horizon-d0aab18cc724>`
.. |software-release-deployment-in-distributed-cloud-overview| replace:: :ref:`Software Release Deployment in Distributed Cloud Overview <software-release-deployment-in-distributed-cloud-overview>`
.. |regionone-and-systemcontroller-modes| replace:: :ref:`RegionOne and SystemController Modes <regionone-and-systemcontroller-modes>`
.. |overview-of-distributed-cloud| replace:: :ref:`Overview of Distributed Cloud <overview-of-distributed-cloud>`
.. |failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud| replace:: :ref:`Failure Prior to the Installation of N+1 Load on a Subcloud <failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud>`
.. |upgrading-the-systemcontroller-using-the-cli| replace:: :ref:`Upgrade the System Controller Using the CLI <upgrading-the-systemcontroller-using-the-cli>`
.. |failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud| replace:: :ref:`Failure During the Installation or Data Migration of N+1 Load on a Subcloud <failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud>`
.. |installing-and-provisioning-the-central-cloud| replace:: :ref:`Install and Provision the Central Cloud <installing-and-provisioning-the-central-cloud>`
.. |uploading-and-applying-updates-to-systemcontroller-using-the-cli| replace:: :ref:`Upload and Apply Updates to SystemController Using the CLI <uploading-and-applying-updates-to-systemcontroller-using-the-cli>`
.. |upload-software-releases-using-the-cli-203af02d6457| replace:: :ref:`Upload Software Releases Using the CLI <upload-software-releases-using-the-cli-203af02d6457>`
.. |deploy-software-releases-using-the-cli-1ea02eb230e5| replace:: :ref:`Deploy Software Releases Using the CLI <deploy-software-releases-using-the-cli-1ea02eb230e5>`
.. |device-image-update-orchestration| replace:: :ref:`Device Image Update Orchestration <device-image-update-orchestration>`
.. |create-a-firmware-update-orchestration-strategy-using-horizon-cfecdb67cef2| replace:: :ref:`Create a Firmware Update Orchestration Strategy using Horizon <create-a-firmware-update-orchestration-strategy-using-horizon-cfecdb67cef2>`
.. |delete-subcloud-groups-22a7c65e66d7| replace:: :ref:`Delete Subcloud Groups Using the Horizon Web Interface <delete-subcloud-groups-22a7c65e66d7>`
.. |rehoming-subcloud-with-expired-certificates-00549c4ea6e2| replace:: :ref:`Rehoming Subcloud with Expired Certificates <rehoming-subcloud-with-expired-certificates-00549c4ea6e2>`
.. |add-a-horizon-keystone-user-to-distributed-cloud-29655b0f0eb9| replace:: :ref:`Add a Horizon/Keystone User to Distributed Cloud <add-a-horizon-keystone-user-to-distributed-cloud-29655b0f0eb9>`
.. |applying-the-update-strategy-for-distributed-cloud| replace:: :ref:`Apply the Update Strategy for Distributed Cloud <applying-the-update-strategy-for-distributed-cloud>`
.. |cli-commands-for-dc-alarms-management| replace:: :ref:`CLI Commands for Distributed Cloud Alarm Management <cli-commands-for-dc-alarms-management>`
.. |creating-an-update-strategy-for-distributed-cloud-update-orchestration| replace:: :ref:`Create an Update Strategy for Distributed Cloud Update Orchestration <creating-an-update-strategy-for-distributed-cloud-update-orchestration>`
.. |rename-subcloud-e303565e7192| replace:: :ref:`Rename a Subcloud <rename-subcloud-e303565e7192>`
.. |updating-docker-registry-credentials-on-a-subcloud| replace:: :ref:`Update Credentials Used by Subcloud for Install Registry (registry.central) <updating-docker-registry-credentials-on-a-subcloud>`
.. |subcloud-deployment-with-local-installation-4982449058d5| replace:: :ref:`Subcloud Deployment with Local Installation <subcloud-deployment-with-local-installation-4982449058d5>`
.. |apply-a-kubernetes-upgrade-strategy-using-horizon-2bb24c72e947| replace:: :ref:`Apply a Kubernetes Upgrade Strategy using Horizon <apply-a-kubernetes-upgrade-strategy-using-horizon-2bb24c72e947>`
.. |update-a-subcloud-network-parameters-b76377641da4| replace:: :ref:`Manage Subcloud Network Parameters <update-a-subcloud-network-parameters-b76377641da4>`
.. |subcloud-deployment-phases-0ce5f6fbf696| replace:: :ref:`Subcloud Deployment Phases <subcloud-deployment-phases-0ce5f6fbf696>`
.. |install-a-subcloud-in-phases-0ce5f6fbf696| replace:: :ref:`Install a Subcloud in Phases <install-a-subcloud-in-phases-0ce5f6fbf696>`
.. |alarms-management-for-distributed-cloud| replace:: :ref:`Alarms Management for Distributed Cloud <alarms-management-for-distributed-cloud>`
.. |distributed-cloud-architecture| replace:: :ref:`Distributed Cloud Architecture <distributed-cloud-architecture>`
.. |reviewing-update-status-for-distributed-cloud-using-horizon| replace:: :ref:`Review Update Status for Distributed Cloud Using Horizon <reviewing-update-status-for-distributed-cloud-using-horizon>`
.. |review-software-release-status-for-distributed-cloud-using-horizon-dashboard| replace:: :ref:`Review Software Release Status for Distributed Cloud Using the Horizon Dashboard <review-software-release-status-for-distributed-cloud-using-horizon-dashboard>`
.. |apply-the-firmware-update-strategy-using-horizon-e78bf11c7189| replace:: :ref:`Apply the Firmware Update Strategy using Horizon <apply-the-firmware-update-strategy-using-horizon-e78bf11c7189>`
.. |edit-subcloud-groups-85232c3a7d33| replace:: :ref:`Edit Subcloud Groups Using the Horizon Web Interface <edit-subcloud-groups-85232c3a7d33>`
.. |managing-subclouds-using-the-cli| replace:: :ref:`Manage Subclouds Using the CLI <managing-subclouds-using-the-cli>`

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

@ -1,21 +0,0 @@
.. 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

33
doc/source/dist_cloud/kubernetes/apply-the-software-deploy-strategy-using-horizon-d0aab18cc724.rst
View File

@ -1,33 +0,0 @@
.. _apply-the-software-deploy-strategy-using-horizon-d0aab18cc724:
================================================
Apply the Software Deploy Strategy using Horizon
================================================
You can upgrade the platform software across the Distributed Cloud
system by applying the upgrade strategy for Distributed Cloud
Upgrade Orchestration.
.. rubric:: |prereq|
Create the Upgrade strategy for subclouds. For more information, see
:ref:`create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706`.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** > **Orchestration**.
#. On the **Orchestration** page, select the **Strategy** tab.
#. Click **Apply Strategy**.
* To monitor the progress of the overall Upgrade orchestration, use the
**Strategy** tab.
* To monitor the progress of host Upgrades on RegionOne or a subcloud, use
the **Host Inventory** page on the subcloud.

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

@ -1,60 +0,0 @@
.. hgc1558615286351
.. _applying-the-update-strategy-for-distributed-cloud:
===============================================
Apply the Update Strategy for Distributed Cloud
===============================================
You can update the platform software across the |prod-dc| system by applying
the update strategy for |prod-dc| Update Orchestration.
.. rubric:: |context|
You can apply the update strategy from the Horizon Web interface or the CLI.
To use the CLI, see :ref:`update-management-for-distributed-cloud`.
.. rubric:: |prereq|
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.
- Install the updates on the SystemController RegionOne.
- Create the update strategy for subclouds.
- Optionally adjust the configuration settings for updating nodes.
For more information, see :ref:`Update Management for Distributed Cloud
<update-management-for-distributed-cloud>`.
.. rubric:: |proc|
.. _applying-the-update-strategy-for-distributed-cloud-steps-hrv-4nl-rdb:
Use |prod-dc| orchestration to update the subclouds:
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Orchestration**.
#. On the **Orchestration** page, select the **Strategy** tab.
#. Click **Apply Strategy**.
To monitor the progress of the overall update orchestration, use the
**Strategy** tab.
To monitor the progress of host updates on a subcloud, use the **Host
Inventory** page on the subcloud.
.. seealso::
:ref:`creating-an-update-strategy-for-distributed-cloud-update-orchestration`
:ref:`customizing-the-update-configuration-for-distributed-cloud-update-orchestration`

4
doc/source/dist_cloud/kubernetes/cli-commands-for-dc-alarms-management.rst
View File

@ -75,8 +75,8 @@ You can use the CLI to review alarm summaries for the |prod-dc|.
.. note::
``829881a8077d4a1f997efd30611cf0ab`` is the desired subcloud region name
and it can be retrieved by using the :command:`dcmanager subcloud show`
``829881a8077d4a1f997efd30611cf0ab`` is the subcloud region name and it
can be retrieved by using the :command:`dcmanager subcloud show <subcloud_name/subcloud_id>`
command. ``192.168.121.2`` is the external_oam_floating_address of the
subcloud.

158
doc/source/dist_cloud/kubernetes/configuration-for-specific-subclouds.rst
View File

@ -1,158 +0,0 @@
.. jul1593180757282
.. _configuration-for-specific-subclouds:
====================================
Configuration for Specific Subclouds
====================================
To determine how upgrades are applied to the nodes on each subcloud, the
upgrade strategy refers to separate configuration settings.
The following settings are applied by default:
.. _configuration-for-specific-subclouds-ul-sgb-p34-gdb:
- storage apply type: parallel
- worker apply type: parallel
- max parallel workers: 10
- alarm restriction type: relaxed
- default instance action: migrate (This parameter is only applicable to
hosted application |VMs| with the |prefix|-openstack application.)
To update the default values, use the :command:`dcmanager strategy-config
update` command. You can also use this command to configure custom behavior for
individual subclouds.
- To list the default upgrade strategy and any custom configurations
configured for individual subclouds, use the :command:`strategy-config
list` command.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-config list
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
| cloud | storage apply type | worker apply type | max parallel workers | alarm restriction type | default instance |
| | | | | | action |
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
| all clouds default | parallel | parallel | 10 | relaxed | migrate |
| subcloud-6 | parallel | parallel | 2 | relaxed | stop-start |
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
- To show the configuration settings applicable to all subclouds by default,
use the :command:`strategy-config show` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-config show
+-------------------------+--------------------+
| Field | Value |
+-------------------------+--------------------+
| cloud | all clouds default |
| storage apply type | parallel |
| worker apply type | parallel |
| max parallel workers | 10 |
| alarm restriction type | relaxed |
| default instance action | migrate |
| created_at | None |
| updated_at | None |
+-------------------------+--------------------+
- To update the settings, or to create a custom configuration for a subcloud,
use the :command:`strategy-config update` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-config update \
\
--storage-apply-type <type> \
--worker-apply-type <type> \
--max-parallel-workers <i> \
--alarm-restriction-type <level> \
--default-instance-action <action> \
[<subcloud_name>]
where
**storage apply type**
parallel or serial — determines whether storage nodes are upgraded in
parallel or serially.
**worker apply type**
parallel or serial — determines whether worker nodes are upgraded in
parallel or serially.
**max parallel workers**
Set the maximum number of worker nodes that can be upgraded in
parallel.
**alarm restriction type**
relaxed or strict — determines whether the orchestration is aborted for
alarms that are not management-affecting. For more information, refer
to the
.. xbooklink :ref:`|updates-doc| <software-updates-and-upgrades-software-updates>` guide.
**default instance action**
.. note::
This parameter is only applicable to hosted application |VMs| with
the |prefix|-openstack application.
migrate or stop-start — determines whether hosted application |VMs| are
migrated or stopped and restarted when a worker host is upgraded
**subcloud_name**
The name of the subcloud to use the custom strategy. If this omitted,
the default upgrade strategy is updated.
.. note::
You must specify all of the settings.
- To show the configuration settings for a subcloud, use the
:command:`strategy-config show` <subcloud> command.
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-config show [<name>]
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-config show subcloud-6
+-------------------------+----------------------------+
| Field | Value |
+-------------------------+----------------------------+
| cloud | subcloud-6 |
| storage apply type | parallel |
| worker apply type | parallel |
| max parallel workers | 2 |
| alarm restriction type | relaxed |
| default instance action | stop-start |
| created_at | 2020-03-12 20:08:48.917866 |
| updated_at | None |
+-------------------------+----------------------------+
If custom configuration settings have not been created for the subcloud,
the following message is displayed:
.. code-block:: none
ERROR (app) No options found for Subcloud with id 1, defaults will be
used.

7
doc/source/dist_cloud/kubernetes/configuring-kubernetes-update-orchestration-on-distributed-cloud.rst
View File

@ -87,10 +87,9 @@ controller for access by subclouds. For example:
.. code-block:: none
~(keystone_admin)]$ sw-patch --os-region-name SystemController upload PLATFORM.1.patch
~(keystone_admin)]$ sw-patch --os-region-name SystemController upload KUBE.1.patch
~(keystone_admin)]$ sw-patch --os-region-name SystemController upload KUBE.2.patch
~(keystone_admin)]$ software --os-region-name SystemController upload PLATFORM.1.patch
~(keystone_admin)]$ software --os-region-name SystemController upload KUBE.1.patch
~(keystone_admin)]$ software --os-region-name SystemController upload KUBE.2.patch
.. rubric:: |proc|

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

@ -1,85 +0,0 @@
.. _create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706:
====================================================
Create a Software Deploy Orchestration using Horizon
====================================================
.. rubric:: |prereq|
You must have completed the procedure in
:ref:`distributed-software-deploy-orchestration-process-using-the-cli`.
.. rubric:: |proc|
#. Review the software deploy status for the subclouds.
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.
#. Select **Distributed Cloud Admin** > **Cloud Overview**.
#. Create the strategy.
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** > **Orchestration**.
#. On the **Orchestration** page, select the **Strategy** tab.
#. Create the new strategy.
On the **Strategy** tab, click **Create Strategy**. In the **Create
Strategy** dialog box, adjust the settings as needed.
**Strategy Type**
Software Deploy
**Release**
Release ID.
This option is available when **Strategy Type** is set to "Software
Deploy".
**Apply to**
Subcloud or Subcloud Group
**Subcloud**
Enter the subcloud name
**Subcloud Group**
Enter the subcloud group name only if you select the **Apply to**:
**Subcloud Group** option.
**Stop on Failure**
Default: True
Determines whether update orchestration failure for a subcloud
prevents application to subsequent subclouds.
**Subcloud Apply Type**
Default: Parallel
Parallel or Serial. Determines whether the subclouds are updated in
parallel or serially.
**Maximum Parallel Subclouds**
Default 20
If this is not specified using the CLI, the values for
``max_parallel_subclouds`` defined for each subcloud group will be
used by default.
#. Adjust how the Software Deploy on subclouds will be performed.
#. Save the new strategy.
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.

10
doc/source/dist_cloud/kubernetes/creating-subcloud-groups.rst → doc/source/dist_cloud/kubernetes/create-edit-and-delete-subcloud-groups-using-the-cli.rst
View File

@ -1,10 +1,10 @@
.. enf1600200276330
.. _creating-subcloud-groups:
.. _create-edit-and-delete-subcloud-groups-using-the-cli:
======================
Create Subcloud Groups
======================
=====================================================
Create, Edit and Delete Subcloud Groups Using the CLI
=====================================================
All subclouds belong to a subcloud group. When a subcloud is created, it will
be added to the 'Default' group, unless a different subcloud group has been
@ -23,7 +23,7 @@ You can use |CLI| commands to add new subcloud groups, list, update or delete
subcloud groups. The |CLI| commands for managing subcloud groups are:
.. _creating-subcloud-groups-ul-fvw-cj4-3jb:
.. _create-edit-and-delete-subcloud-groups-using-the-cli-ul-fvw-cj4-3jb:
:command:`dcmanager subcloud-group add`:
Adds a new subcloud group.

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

@ -1,117 +0,0 @@
.. rmf1558615469496
.. _creating-an-update-strategy-for-distributed-cloud-update-orchestration:
====================================================================
Create an Update Strategy for Distributed Cloud Update Orchestration
====================================================================
To update previous release subclouds with updates in the **Partial-Apply**
state, you must create an update strategy for |prod-dc| Update Orchestration.
After an update is **activated/completed/deleted** on the Central Cloud's
RegionOne, the subclouds are audited and their patching sync status is updated.
This can take up to 15 minutes.
If the Subclouds are in a **Managed** state and if the patching sync status is
"out-of-sync", it can be orchestrated.
.. rubric:: |context|
Only one update strategy can exist at a time. The strategy controls how the
subclouds are updated (for example, serially or in parallel).
To determine how the nodes on each subcloud are updated, the update strategy
refers to separate configuration settings available on the **Subcloud Strategy
Configurations** tab.
.. rubric:: |prereq|
You must be in **SystemController** region. To change the region, see
:ref:`regionone-and-systemcontroller-modes`.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Orchestration**.
#. On the **Orchestration** page, select the **Strategy**
tab.
#. Click **Create Strategy**.
In the **Create Strategy** dialog box, adjust the settings as needed.
**Strategy Type**
Patch.
**Patch**
The patch ID to upload/apply on the subcloud.
**Apply to**
Subcloud or Subcloud Group.
**Subcloud**
Select the subcloud name, only if you have chosen the **Apply to:
Subcloud** option.
**Subcloud Group**
Write the subcloud group name, only if you select the **Apply to:
Subcloud Group** option.
**Stop on Failure**
default true — determines whether update orchestration failure for a
subcloud prevents application to subsequent subclouds.
**Subcloud Apply Type**
Parallel or Serial, default Parallel — determines whether the subclouds
are updated in parallel or serially.
This option is available when **Apply to** is set to "Subcloud" and
**Subcloud** is set to **All subclouds**.
**Maximum Parallel Subclouds**
default 20 — If this is not specified using the |CLI|, the values for
max_parallel_subclouds defined for each subcloud group will be used by
default.
This option is available when **Apply to** is set to "Subcloud" and
**Subcloud** is set to **All subclouds**.
**Upload Only**
Stops strategy after uploading patches to subclouds.
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`.
#. Click **Create Strategy**.
Only subclouds in the **Managed** state and whose patching sync status is
out-of-sync are added to the list. To change the update strategy settings,
you must delete the update 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 displayed. The user can apply
the strategy or verify if it is still valid.
.. image:: figures/update-strategy-4.png
.. note::
To change the update strategy settings, you must delete the update
strategy and create a new one.
.. seealso::
:ref:`customizing-the-update-configuration-for-distributed-cloud-update-orchestration`
:ref:`applying-the-update-strategy-for-distributed-cloud`

98
doc/source/dist_cloud/kubernetes/customizing-the-update-configuration-for-distributed-cloud-update-orchestration.rst
View File

@ -1,98 +0,0 @@
.. sku1558615443333
.. _customizing-the-update-configuration-for-distributed-cloud-update-orchestration:
=============================================================================
Customize the Update Configuration for Distributed Cloud Update Orchestration
=============================================================================
You can adjust how the nodes in each subcloud are updated.
.. rubric:: |context|
The update strategy for |prod-dc| Update Orchestration uses separate
configuration settings to control how the nodes on a given system are updated.
You can adjust the settings used by default for all subclouds, and you can
create custom settings for individual subclouds.
You can change the configuration settings before or after creating a update
strategy for |prod-dc| update orchestration. The settings are maintained
independently.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Orchestration**.
#. On the **Orchestration** page, select the **Subcloud Strategy
Configurations** tab.
.. image:: figures/orchestration-subcloud-strategy-config-tab.png
:width: 1000px
Take one of the following actions:
- To edit the settings applicable to all subclouds by default, click
**Edit Configuration** in the **all clouds default** row.
.. image:: figures/brk1525194697928.png
To save your changes, click **Edit Subcloud Strategy Configurations**.
- To create custom settings for an individual subcloud, click **Create
New Subcloud Strategy Configurations**.
In the **Subcloud** field, select the subcloud for the custom settings.
To save your configuration changes, click **Create Subcloud Strategy
Configurations**. The new configuration is added to the list.
.. image:: figures/vwa1525194889921.png
The following settings are available:
**Subcloud**
This specifies the subcloud affected by the configuration. For the
**all clouds default** configuration, this setting cannot be changed.
**Storage Apply Type**
Parallel or Serial — determines whether storage nodes are patched in
parallel or serially
**Worker Apply Type**
Parallel or Serial — determines whether worker nodes are patched in
parallel or serially
**Maximum Parallel Worker Hosts**
This sets the maximum number of worker nodes that can be patched in
parallel.
**Default Instance Action**
.. note::
This parameter is only applicable to hosted application VMs with
the |prefix|-openstack application.
migrate or stop-start — determines whether hosted application VMs are
migrated or stopped and restarted when a worker host is upgraded
**Alarm Restrictions**
Relaxed or Strict — determines whether the orchestration is aborted for
alarms that are not management-affecting.
.. rubric:: |postreq|
For information about creating and applying a patch strategy, see
:ref:`update-management-for-distributed-cloud`.
**Related information**
.. seealso::
:ref:`creating-an-update-strategy-for-distributed-cloud-update-orchestration`
:ref:`applying-the-update-strategy-for-distributed-cloud`

273
doc/source/dist_cloud/kubernetes/distributed-software-deploy-orchestration-process-using-the-cli.rst → doc/source/dist_cloud/kubernetes/deploy-software-releases-using-the-cli-1ea02eb230e5.rst
View File

@ -1,107 +1,100 @@
.. pek1594745988225
.. _distributed-software-deploy-orchestration-process-using-the-cli:
.. WARNING: Add no lines of text between the label immediately following
.. and the title.
===============================================================
Distributed Software Deploy Orchestration Process using the CLI
===============================================================
.. _deploy-software-releases-using-the-cli-1ea02eb230e5:
Distributed software deploy orchestration can be initiated after the System
Controller has been successfully updated (patch) or deployed.
======================================
Deploy Software Releases using the CLI
======================================
For more information on Prestaging Subcloud Orchestration see,
:ref:`prestage-subcloud-orchestration-eb516473582f`.
After a software release has been uploaded to the central repository, it can be
deployed first on the System Controller and then on a specific subcloud or
across a group of subclouds through different orchestration methods.
Deploy a Software Release on the System Controller
--------------------------------------------------
Follow the instructions at
:ref:`orchestrated-deployment-host-software-deployment-d234754c7d20` to
complete the software deployment.
.. note::
This section is applicable to users that use the dcmanager software deploy
orchestration strategy to manage upgrades across subclouds.
The step to upload the software release can be skipped since it has already
been done.
Refer to |updates-doc| for more details.
It is recommended to upgrade Kubernetes following the deployment of a major
release. See :ref:`the-kubernetes-update-orchestration-process`.
.. rubric:: |context|
The System Controller is now ready for new subcloud deployment.
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:
.. note::
Starting release |prod-ver|, low-latency configuration via remote install
is no longer supported.
For new subcloud deployments that involve remote install using Redfish,
avoid using ``install_type`` of 4 and 5 in ``install-values.yaml``.
For existing subclouds that were originally deployed with remote install,
use :command:`dcmanager subcloud update --install-values` to update the
``install_type`` so they can be restored in the future.
.. _distributed-upgrade-orchestration-process-using-the-cli-ul-eyw-fyr-31b:
Orchestrate the Deployment of a Software Release Across the Subclouds
---------------------------------------------------------------------
- whether to stop on failure of a subcloud update/upgrade or continue with
the next subcloud
After the System Controller has been successfully updated with a new major or
patch software release; distributed software deployment orchestration can be
initiated to bring the managed subclouds to the same software level as the
System Controller. The subclouds must, however, be prestaged with the target
software before orchestrated deployment can take place.
- whether to update/upgrade hosts serially or in parallel
For more information on Prestaging Subcloud Orchestration see
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f`.
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.
Before orchestrating a major software release deployment across the subclouds,
it is strongly recommended that a backup of each subcloud to be upgraded is
taken. See
:ref:`backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42`
for instructions.
.. rubric:: |prereq|
Distributed software deploy orchestration can only be done on a system that
meets the following conditions:
The following conditions must be met for the orchestrated software deployment
across the subclouds to be successful.
.. _distributed-upgrade-orchestration-process-using-the-cli-ul-blp-gcx-ry:
- All target subclouds are managed, online and healthy. The Kubernetes
cluster on each subcloud is fully operational and there are no management
affecting alarms.
- All subclouds are clear of management-affecting alarms (with the exception
of the alarm upgrade in progress).
- Subcloud certificates are up-to-date or will not expire during the
deployment of the new software release.
- All hosts of all subclouds must be unlocked, enabled, and available.
- All target subclouds have been prestaged with the software release and the
new container images required for that release. See
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f` for
instructions.
- All subclouds should have been prestaged (``--for-sw-deploy``).
- For the deployment of major software release, ensure that the controller-0
is the active controller on each subcloud.
- |Optional| **Only for Major Release** Upload the new software release to
the central software release repository:
.. 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
on a subcloud, use the following command to view the details of its
persistent file system:
:command:`df -Th /opt/platform-backup`
The type must be ext4 and the size must be 30GiB. For example, on
controller-0, run the following command:
.. code-block:: none
~(keystone_admin)]$ df -Th /opt/platform-backup
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 29G 6.9G 21G 26% /opt/platform-backup
- **If a previous upgrade has been done on the subcloud**, from the shell on
each subcloud, use the following command to remove the previous upgrade
data:
:command:`sudo rm /opt/platform-backup/upgrade_data\*`
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`.
~(keystone_admin)]$ software --os-region-name SystemController upload <bootimage.iso> <bootimage.sig>
.. rubric:: |proc|
.. _distributed-upgrade-orchestration-process-using-the-cli-steps-vcm-pq4-3mb:
#. Review software sync status of the subclouds.
#. Review the software status for the subclouds.
After the System Controller upgrade/deploy is completed, wait for 40
seconds for the **software_sync_status** of all subclouds to be updated.
After new software release has been deployed on the System Controller, wait
for approximately 60 seconds for the ``software_sync_status`` of all
subclouds to be updated.
To identify which subclouds are deploy-current (in-sync), use the
:command:`subcloud list` command. For example:
:command:`dcmanager subcloud list` command. For example:
.. code-block:: none
@ -115,45 +108,46 @@ Horizon, see
| 4 | subcloud-4| managed | online | out-of-sync |
+----+-----------+--------------+--------------------+-------------+
.. note::
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:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show subcloud1
+-----------------------------+------------------------------+
| Field | Value |
+-----------------------------+------------------------------+
| id | 1 |
| name | subcloud-1 |
| description | None |
| location | None |
| software_version | nn.nn |
| management | managed |
| availability | online |
| deploy_status | complete |
| management_subnet | fd01:82::0/64 |
| management_start_ip | fd01:82::2 |
| management_end_ip | fd01:82::11 |
| management_gateway_ip | fd01:82::1 |
| systemcontroller_gateway_ip | fd01:81::1 |
| group_id | 1 |
| created_at | 2021-06-07 21:05:16.224664 |
| updated_at | 2021-06-09 20:01:37.525012 |
| dc-cert_sync_status | in-sync |
| firmware_sync_status | in-sync |
| identity_sync_status | in-sync |
| kubernetes_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 |
+-----------------------------+------------------------------+
+-----------------------------+----------------------------------+
| Field | Value |
+-----------------------------+----------------------------------+
| id | 2 |
| name | subcloud1-stx-latest |
| description | Ottawa Site |
| location | YOW |
| software_version | 24.09 |
| management | unmanaged |
| availability | online |
| deploy_status | complete |
| management_subnet | 192.168.101.0/24 |
| management_start_ip | 192.168.101.2 |
| management_end_ip | 192.168.101.50 |
| management_gateway_ip | 192.168.101.1 |
| systemcontroller_gateway_ip | 192.168.204.101 |
| group_id | 1 |
| peer_group_id | None |
| created_at | 2025-01-21 18:34:30.410350 |
| updated_at | 2025-01-21 19:03:08.836619 |
| backup_status | None |
| backup_datetime | None |
| prestage_status | None |
| prestage_versions | None |
| dc-cert_sync_status | in-sync |
| firmware_sync_status | unknown |
| identity_sync_status | unknown |
| kubernetes_sync_status | unknown |
| kube-rootca_sync_status | unknown |
| load_sync_status | unknown |
| patching_sync_status | unknown |
| platform_sync_status | unknown |
| software_sync_status | unknown |
| region_name | 0aa48e9b72bf48bbaad9a624cdd0cacb |
+-----------------------------+----------------------------------+
#. To create a sw-deploy strategy, use the :command:`dcmanager sw-deploy-strategy create <release_id>`
command.
@ -163,7 +157,7 @@ Horizon, see
.. code-block:: none
~(keystone_admin)]$ dcmanager sw-deploy-strategy create \
~(keystone_admin)]$ dcmanager sw-deploy-strategy create \
[--subcloud-apply-type <type>] \
[–-max-parallel-subclouds <i>] \
[–-stop-on-failure <level>] \
@ -173,8 +167,8 @@ Horizon, see
where:
**subcloud-apply-type**
**parallel** or **serial**— determines whether the subclouds are
upgraded in parallel, or serially.
**parallel** or **serial**— determines whether the subclouds will be
processed in parallel or serially.
If this is not specified using the CLI, the values for
:command:`subcloud_update_type` defined for each subcloud group will
@ -209,11 +203,12 @@ Horizon, see
| Field | Value |
+------------------------+----------------------------+
| strategy type | sw-deploy |
| subcloud apply type | parallel |
| subcloud apply type | None |
| max parallel subclouds | 2 |
| stop on failure | False |
| release_id | WRCP-24.09.200 |
| state | initial |
| created_at | 2024-11-06 12:56:17.111621 |
| created_at | 2025-01-21T20:00:31.141872 |
| updated_at | None |
+------------------------+----------------------------+
@ -244,21 +239,18 @@ Horizon, see
#. Review the sw-deploy strategy for the subclouds.
To show the subclouds that will be upgraded when the sw-deploy strategy is
To show the subclouds that will be processed 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 |
+----------------------+-------+---------+---------+------------+-------------+
| subcloud1-stx-latest | 1 | initial | | None | None |
+----------------------+-------+---------+---------+------------+-------------+
.. note::
@ -306,9 +298,10 @@ Horizon, see
~(keystone_admin)]$ dcmanager strategy-step show <subcloud>
#. 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.
#. When all the subclouds within the distributed software deploy orchestration
indicate they have entered either the complete or failed state, delete the
sw-deploy strategy, using the :command:`dcmanager sw-deploy-strategy delete`
command.
.. code-block:: none
@ -324,15 +317,27 @@ Horizon, see
| updated_at | 2020-03-23T20:05:14.157352 |
+------------------------+----------------------------+
.. note::
Before attempting to log in to the subclouds using the sysadmin account,
verify that the subcloud ``platform_sync_status`` is synced. This would
ensure that the sysadmin password is successfully resynced to the subclouds
and that login attempts do not fail.
.. only:: partner
.. rubric:: |postreq|
.. include:: /_includes/distributed-upgrade-orchestration-process-using-the-cli.rest
:start-after: DMupgrade-begin
:end-before: DMupgrade-end
If the subclouds are upgraded with a major software release, it is recommended
to also upversion Kubernetes right after the software deployment. See
:ref:`kubernetes-upversion-orchestration`.
Error Handling During an Orchestrated Subcloud Software Deployment
------------------------------------------------------------------
If a failure occurs, follow the general steps below:
#. Allow the failed strategy to complete on its own.
#. Check the output using :command:`dcmanager strategy-step list` command.
#. To see the cause of failure for a subcloud, use the :command:`dcmanager subcloud errors <subcloud-name/subcloud-id>`
command.
#. Resolve the condition that caused the failure.
#. Retry the orchestration by deleting the failed strategy and create a new
one for the failed subcloud(s).

287
doc/source/dist_cloud/kubernetes/deploy-software-releases-using-the-horizon-dashboard-eea2f49efc2c.rst Normal file
View File

@ -0,0 +1,287 @@
.. WARNING: Add no lines of text between the label immediately following
.. and the title.
.. _deploy-software-releases-using-the-horizon-dashboard-eea2f49efc2c:
====================================================
Deploy Software Releases Using the Horizon Dashboard
====================================================
After a software release has been uploaded to the central repository, it can be
deployed first on the System Controller and then on a specific subcloud or
across a group of subclouds through different orchestration methods. If a CLI
is preferred, see :ref:`deploy-software-releases-using-the-cli-1ea02eb230e5`.
Deploy a Software Release on the System Controller
--------------------------------------------------
.. rubric:: |proc|
#. Change to the RegionOne region (top left drop-down menu).
.. image:: figures/change_to_regionone.png
#. Go to **Admin** > **Platform** > **Software Management** and open the
**Deploy Orchestration** tab.
.. image:: figures/software-management-deploy-orchestration-tab.png
#. Select **Create Strategy**.
#. Create a Software Deploy strategy by specifying the settings for the
parameters in the **Create Strategy** dialog box.
.. image:: figures/create-software-deploy-strategy-pop.png
.. note::
Ensure the **Delete** checkbox is selected. If not, the deployment must
be manually deleted via the CLI using the :command:`software deploy delete`
command after the strategy is completed. Failure to do so will prevent
the subclouds' software release sync state from being marked as
out-of-sync, which will block the orchestration of the software
deployment on the subclouds.
#. Click **Create Software Deploy Strategy** to confirm the strategy creation.
.. note::
To change the strategy settings, you must delete the strategy and
create a new one.
#. Wait for the strategy status of the build phase to reach **success**.
#. Click on **Apply Strategy** to start deploying the software release.
#. Wait for the strategy to finish applying.
.. image:: figures/software-deploy-strategy-deploy-orchestration.png
#. Once the new software release is applied, click **Delete Strategy** to
delete the strategy.
Orchestrate the Deployment of a Software Release Across the Subclouds
---------------------------------------------------------------------
After the System Controller has been successfully updated with a new major or
patch software release; distributed software deployment orchestration can be
initiated to bring the managed subclouds to the same software level as the
System Controller. The subclouds must, however, be prestaged with the target
software before orchestrated deployment can take place.
For more information on Prestaging Subcloud Orchestration see
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f`.
Before orchestrating a major software release deployment across the subclouds,
it is strongly recommended that a backup of each subcloud to be upgraded is
taken. See
:ref:`backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42`
for instructions.
.. rubric:: |prereq|
The following conditions must be met for the orchestrated software deployment
across the subclouds to be successful.
- All target subclouds are managed, online and healthy. The Kubernetes
cluster on each subcloud is fully operational and there are no management
affecting alarms.
- Subcloud certificates are up-to-date or will not expire during the
deployment of the new software release.
- All target subclouds have been prestaged with the software release and the
new container images required for that release. See
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f` for
instructions.
- For the deployment of major software release, ensure that the controller-0
is the active controller on each subcloud.
- The subclouds' software sync status must be out of sync.
.. rubric:: |proc|
#. Select the SystemController region.
.. image:: figures/system-controller-region.png
#. Select Distributed **Cloud Admin** > **Orchestration**.
#. On the **Orchestration** page, select the **Strategy** tab.
.. image:: figures/orchestration-page-strategy-tab.png
#. Create a new strategy.
On the **Strategy** tab, click Create **Strategy**. In the **Create
Strategy** dialog box, select the Software Deploy strategy type and adjust
the settings as needed.
.. image:: figures/create-strategy-form.png
**Strategy Type**
Software Deploy.
**Release**
Release ID.
This option is available when Strategy Type is set to Sw-Deploy.
**Apply to**
Subcloud or Subcloud Group.
**Subcloud**
Select the subcloud name or All Subclouds.
**Subcloud Group**
Select the subcloud group. Available only if you select the **Apply to:
Subcloud Group** option.
**Stop on Failure**
Default: True.
Determines whether update orchestration failure for a subcloud prevents
application to subsequent subclouds.
**Subcloud Apply Type**
Default: Parallel.
Parallel or Serial. Determines whether the subclouds are updated in
parallel or serially.
**Maximum Parallel Subclouds**
Default: 20.
Defines the maximum number of subclouds on which the software
deployment can run in parallel. If the **Apply to: Subcloud Group**
option is selected, it will use the ``max_parallel_subclouds`` value of
the subcloud group instead.
#. Click **Create Strategy** to confirm the operation.
#. Click **Apply Strategy** to start applying the software release update to
the subclouds.
As each subcloud is deployed, it moves through the following states:
**initial**
The orchestration has not yet started.
**sw-deploy pre-check**
Verify that the subcloud has no existing strategies, that it was
pre-staged, and that the System Controller already has the specified
release deployed.
**sw-deploy install license** (only for major releases)
Installing release license.
**create VIM sw-deploy strategy**
The strategy is being created in the subcloud.
**apply VIM sw-deploy strategy**
The strategy is being applied in the subcloud.
**finish sw-deploy strategy**
Updates that are no longer required are being deleted.
Updates that require committing are being committed.
**complete**
The software release has been deployed successfully.
#. Once the strategy state changes to **complete**, click Delete Strategy to
delete it.
.. image:: figures/strategy-delete.png
.. _customizing-the-update-configuration-for-distributed-cloud-update-orchestration:
-----------------------------------------------------------------------------
Customize the Update Configuration for Distributed Cloud Update Orchestration
-----------------------------------------------------------------------------
You can adjust how the nodes in each subcloud are updated.
.. rubric:: |context|
The update strategy for |prod-dc| Update Orchestration uses separate
configuration settings to control how the nodes on a given system are updated.
You can adjust the settings used by default for all subclouds, and you can
create custom settings for individual subclouds.
You can change the configuration settings before or after creating an update
strategy for |prod-dc| update orchestration. The settings are maintained
independently.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Orchestration**.
#. On the **Orchestration** page, select the **Subcloud Strategy
Configurations** tab.
.. image:: figures/orchestration-subcloud-strategy-config-tab.png
:width: 1000px
Take one of the following actions:
- To edit the settings applicable to all subclouds by default, click
**Edit Configuration** in the **all clouds default** row.
.. image:: figures/edit-subcloud-strategy-configuration.png
To save your changes, click **Edit Subcloud Strategy Configurations**.
- To create custom settings for an individual subcloud, click **Create
New Subcloud Strategy Configurations**.
In the **Subcloud** field, select the subcloud for the custom settings.
To save your configuration changes, click **Create Subcloud Strategy
Configurations**. The new configuration is added to the list.
.. image:: figures/subcloud-strategy-configurations.png
The following settings are available:
**Subcloud**
This specifies the subcloud affected by the configuration. For the
**all clouds default** configuration, this setting cannot be changed.
**Storage Apply Type**
Parallel or Serial — determines whether storage nodes are patched in
parallel or serially
**Worker Apply Type**
Parallel or Serial — determines whether worker nodes are patched in
parallel or serially
**Maximum Parallel Worker Hosts**
This sets the maximum number of worker nodes that can be patched in
parallel.
**Default Instance Action**
.. note::
This parameter is only applicable to hosted application VMs with
the |prefix|-openstack application.
migrate or stop-start — determines whether hosted application VMs are
migrated or stopped and restarted when a worker host is upgraded
**Alarm Restrictions**
Relaxed or Strict — determines whether the orchestration is aborted for
alarms that are not management-affecting.
.. rubric:: |postreq|
For information about creating and applying a patch strategy, see
:ref:`software-release-deployment-in-distributed-cloud-overview`.

38
doc/source/dist_cloud/kubernetes/distributed-cloud-architecture.rst
View File

@ -11,7 +11,7 @@ connected to the Central Cloud over L3 networks.
The Central Cloud has two regions: RegionOne, used to manage the nodes in the
Central Cloud, and system controller, used to manage the subclouds in the
|prod-dc| system. You can select RegionOne or system controller regions from the
Horizon Web interface or by setting the <OS_REGION_NAME> environment variable
Horizon Web interface or by using the ``--os-region-name <region-name>`` option
if using the CLI.
**Central Cloud**
@ -19,28 +19,22 @@ if using the CLI.
platform of the Central Cloud and the system controller region for managing
and orchestrating over the subclouds.
The Central Cloud does not support worker hosts. All worker functions are
performed at the subcloud level.
**RegionOne**
RegionOne is the name of the access mode, or region, for managing the
Central Cloud's physical platform.
**RegionOne**
RegionOne is the name of the access mode, or region, for managing the
Central Cloud's physical platform.
**System Controller**
The system controller access mode, or region, for managing subclouds is
System Controller.
**System Controller**
The system controller access mode, or region, for managing subclouds is
System Controller.
You can use the system controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations and
alarms. You can also access the individual subclouds through the single
central Horizon interface at the Central Cloud to perform subcloud-specific
operations such as configuring and managing the subclouds' host nodes and
containers. System software updates for the subclouds are also centrally
managed and applied from the system controller.
You can use the system controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations and
alarms. You can also access the individual subclouds through the single
central Horizon interface at the Central Cloud to perform subcloud-specific
operations such as configuring and managing the subclouds' host nodes and
containers. System software updates for the subclouds are also centrally
managed and applied from the system controller.
DNS and other select configuration settings are centrally managed at the
system controller and pushed to the subclouds in parallel to maintain
synchronization across the |prod-dc|.
**Subclouds**
The subclouds are |prod| instances used to host containerized applications.
@ -77,8 +71,8 @@ if using the CLI.
**Networks**
Subclouds are connected to the system controller over L3 Networks. They are
connected via the |OAM| Network by either the management network or the admin
network.
connected via the |OAM| Network and by either the Management Network or the
Admin Network.
.. note::

112
doc/source/dist_cloud/kubernetes/failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud.rst
View File

@ -1,112 +0,0 @@
.. oeo1597292999568
.. _failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud:
===========================================================================
Failure During the Installation or Data Migration of N+1 Load on a Subcloud
===========================================================================
You may encounter some errors during Installation or Data migration of the
**N+1** load on a subcloud. This section explains the errors and the steps
required to fix these errors.
.. contents:: |minitoc|
:local:
:depth: 1
Errors can occur due to one of the following:
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-ul-j5r-czs-qmb:
- One or more invalid install values
- A network error that results in the subcloud being temporarily unreachable
To get detailed information about errors during installation or data migration,
run the :command:`dcmanager subcloud errors <subcloud_name/subcloud_id>` command.
If you are using the web interface, you can get the error details within the
corresponding strategy step or access the comprehensive information related to
the affected subcloud. To do so, navigate to the subcloud view and click
**Distributed Cloud Admin > Cloud Overview**. In the given list of subclouds,
expand a specific subcloud. You can see any error messages at the end of the
details for each subcloud.
**Failure Caused by Install Values**
If the subcloud install values contain an incorrect value, use the following
command to fix it.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud update <subcloud-name> --install-values <subcloud-install-values-yaml>
This type of failure is recoverable and you can retry the orchestrated
upgrade for each of the failed subclouds using the following procedure:
.. rubric:: |proc|
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-ol-lc1-cyr-qmb:
#. Delete the failed upgrade strategy.
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy delete
#. Create a new upgrade strategy for the failed subcloud.
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy create <subcloud-name> --force <additional options>
.. note::
If the upgrade failed during the |AIO|-SX upgrade or data migration, the
subcloud availability status is displayed as 'offline'. Use the
:command:`--force` option when creating the new strategy.
#. Apply the new upgrade strategy.
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy apply
#. Verify the upgrade strategy status.
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-step list
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-section-f5f-j1y-qmb:
-----------------------------------------
Failure Post Data Migration on a Subcloud
-----------------------------------------
Once the data migration on the subcloud is completed, the upgrade is activated
and finalized. If failure occurs:
.. rubric:: |proc|
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-ul-ogc-cp5-qmb:
- Get detailed information about errors during activation step by running the
:command:`dcmanager subcloud errors <subcloud_name/subcloud_id>` command.
- If you are using the web interface, you can get the error details within the
corresponding strategy step or access the comprehensive information related to
the affected subcloud. To do so, navigate to the subcloud view and click **Distributed
Cloud Admin > Cloud Overview**. In the given list of subclouds, expand a
specific subcloud. You can see any error messages at the end of the
details for each subcloud.
- Check specified log files
- Follow the recovery procedure. See :ref:`failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud`
.. only:: partner
.. include:: /_includes/distributed-upgrade-orchestration-process-using-the-cli.rest

61
doc/source/dist_cloud/kubernetes/failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud.rst
View File

@ -1,61 +0,0 @@
.. uvp1597292940831
.. _failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud:
===========================================================
Failure Prior to the Installation of N+1 Load on a Subcloud
===========================================================
You may encounter some errors prior to Installation of the **N+1** load on a
subcloud. This section explains the errors and the steps required to fix these
errors.
Errors can occur due to any one of the following:
.. _failure-prior-to-the-installation-of-n+1-load-on-a-subcloud-ul-onf-2vs-qmb:
- Insufficient disk space on scratch filesystems
- Missing subcloud install values
- Invalid license
- Invalid/corrupted load file
- The /home/sysadmin directory on the subcloud is too large
If you encounter any of the above errors, follow this procedure to retry the
orchestrated upgrade after addressing the cause of failure:
.. rubric:: |proc|
#. Delete the failed upgrade strategy
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy delete
#. Create a new upgrade strategy.
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy create <additional options>
.. note::
If only one subcloud fails the upgrade, specify the name of the
subcloud in the command.
#. Apply the new upgrade strategy.
.. code-block:: none
~(keystone_admin)]$ dcmanager upgrade-strategy apply
#. Verify the upgrade strategy status
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-step list

BIN
doc/source/dist_cloud/kubernetes/figures/apply-to-all-subclouds.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/apply-to-subcloud-option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/change_to_regionone.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/create-software-deploy-strategy-pop.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 94 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/create-strategy-form.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 107 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/create-strategy-prestage.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 80 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/edit-subcloud-strategy-configuration.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/monitor-subclouds-horizon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 140 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/orchestration-page-strategy-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/orchestration-strategy-steps-table.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 70 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/releases-list-state.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/software-deploy-strategy-deploy-orchestration.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 94 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/software-management-deploy-orchestration-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/software-management-system-controller.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 78 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/strategy-delete.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/subcloud-group-new.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/subcloud-strategy-configurations.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/system-controller-region.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
doc/source/dist_cloud/kubernetes/figures/upload-releases-pop.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

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

@ -35,14 +35,29 @@ Installation
installing-and-provisioning-a-subcloud
installing-a-subcloud-using-redfish-platform-management-service
installing-a-subcloud-without-redfish-platform-management-service
subcloud-deployment-phases-0ce5f6fbf696
install-a-subcloud-in-phases-0ce5f6fbf696
reinstalling-a-subcloud-with-redfish-platform-management-service
subcloud-deployment-with-local-installation-4982449058d5
enroll-a-factory-installed-nondc-standalone-system-as-a-s-87b2fbf81be3
---------
Operation
---------
--------------------------
Subcloud Groups Management
--------------------------
.. toctree::
:maxdepth: 1
managing-subcloud-groups
create-edit-and-delete-subcloud-groups-using-the-cli
create-subcloud-groups-using-the-horizon-web-interface-69d357303531
edit-subcloud-groups-85232c3a7d33
delete-subcloud-groups-22a7c65e66d7
orchestration-strategy-using-subcloud-groups
----------
Operations
----------
.. toctree::
:maxdepth: 1
@ -66,84 +81,36 @@ Operation
add-a-horizon-keystone-user-to-distributed-cloud-29655b0f0eb9
update-a-subcloud-network-parameters-b76377641da4
--------------------------------------------------------------------
Prestage Orchestration for Distributed Cloud Subclouds using the CLI
--------------------------------------------------------------------
-------------------------------
Subcloud Prestage Orchestration
-------------------------------
.. toctree::
:maxdepth: 1
prestage-subcloud-orchestration-eb516473582f
orchestrate-subcloud-prestage-using-the-cli-eb516473582f
orchestrate-subcloud-prestage-using-the-horizon-dashboard-bdc02df7a2b2
----------------------
Manage Subcloud Groups
----------------------
.. toctree::
:maxdepth: 1
managing-subcloud-groups
creating-subcloud-groups
create-subcloud-groups-using-the-horizon-web-interface-69d357303531
edit-subcloud-groups-85232c3a7d33
delete-subcloud-groups-22a7c65e66d7
orchestration-strategy-using-subcloud-groups
--------------------------------------------------------
Deploy, Restore and Manage Subclouds of Previous Release
--------------------------------------------------------
.. toctree::
:maxdepth: 1
deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b
-------------------------
Update (Patch) management
-------------------------
-----------------------------------------
Software Release Deployment Orchestration
-----------------------------------------
.. toctree::
:maxdepth: 1
update-management-for-distributed-cloud
reviewing-update-status-for-distributed-cloud-using-horizon
reviewing-update-status-for-distributed-cloud-using-the-cli
uploading-and-applying-updates-to-systemcontroller-using-horizon
uploading-and-applying-updates-to-systemcontroller-using-the-cli
software-release-deployment-in-distributed-cloud-overview
review-software-release-status-for-distributed-cloud-using-the-cli
upload-software-releases-using-the-cli-203af02d6457
deploy-software-releases-using-the-cli-1ea02eb230e5
review-software-release-status-for-distributed-cloud-using-horizon-dashboard
upload-software-releases-using-the-horizon-dashboard-67b418278e55
deploy-software-releases-using-the-horizon-dashboard-eea2f49efc2c
***************************************************************
Update orchestration of Central Cloud's RegionOne and subclouds
***************************************************************
.. _kubernetes-upversion-orchestration:
.. toctree::
:maxdepth: 1
update-orchestration-of-central-clouds-regionone-and-subclouds
creating-an-update-strategy-for-distributed-cloud-update-orchestration
customizing-the-update-configuration-for-distributed-cloud-update-orchestration
applying-the-update-strategy-for-distributed-cloud
.. toctree::
:maxdepth: 1
update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli
-----------------------------------
FPGA device image update management
-----------------------------------
.. toctree::
:maxdepth: 1
device-image-update-orchestration
create-a-firmware-update-orchestration-strategy-using-horizon-cfecdb67cef2
apply-the-firmware-update-strategy-using-horizon-e78bf11c7189
--------------------------------------------------------------------
Configure Kubernetes Version Upgrade Distributed Cloud Orchestration
--------------------------------------------------------------------
----------------------------------
Kubernetes Upversion Orchestration
----------------------------------
.. toctree::
:maxdepth: 1
@ -153,40 +120,23 @@ Configure Kubernetes Version Upgrade Distributed Cloud Orchestration
create-a-kubernetes-upgrade-orchestration-using-horizon-16742b62ffb2
apply-a-kubernetes-upgrade-strategy-using-horizon-2bb24c72e947
---------------------------------------------------------
Kubernetes Root CA Update Distributed Cloud Orchestration
---------------------------------------------------------
---------------------------------------
Kubernetes Root CA Update Orchestration
---------------------------------------
.. toctree::
:maxdepth: 1
orchestration-commands-for-dcmanager-4947f9fb9588
------------------
Upgrade management
------------------
--------------------------------------------------------
Deploy, Restore and Manage Subclouds of Previous Release
--------------------------------------------------------
.. toctree::
:maxdepth: 1
upgrade-management-overview
upgrading-the-systemcontroller-using-the-cli
*****************************************************
Upgrade Orchestration for Distributed Cloud SubClouds
*****************************************************
.. toctree::
:maxdepth: 1
distributed-software-deploy-orchestration-process-using-the-cli
create-a-software-deploy-orchestration-using-horizon-9f8c6c2f3706
apply-the-software-deploy-strategy-using-horizon-d0aab18cc724
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
failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud
subclouds-previous-release-management-5e986615cb4b
--------------------------------------------------
Distributed Cloud System Controller GEO Redundancy
@ -198,9 +148,9 @@ Distributed Cloud System Controller GEO Redundancy
overview-of-distributed-cloud-geo-redundancy
configure-distributed-cloud-system-controller-geo-redundancy-e3a31d6bf662
-----------------------------
Management Network Parameters
-----------------------------
-------------------------------------------
Subcloud Management Network Reconfiguration
-------------------------------------------
.. toctree::
:maxdepth: 1
@ -219,3 +169,17 @@ Appendix
distributed-cloud-ports-reference
certificate-management-for-admin-rest-api-endpoints
subcloud-geo-redundancy-error-root-cause-correction-action-43449d658aae
**********
Deprecated
**********
FPGA device image update management
-----------------------------------
.. toctree::
:maxdepth: 1
device-image-update-orchestration
create-a-firmware-update-orchestration-strategy-using-horizon-cfecdb67cef2
apply-the-firmware-update-strategy-using-horizon-e78bf11c7189

11
doc/source/dist_cloud/kubernetes/subcloud-deployment-phases-0ce5f6fbf696.rst → doc/source/dist_cloud/kubernetes/install-a-subcloud-in-phases-0ce5f6fbf696.rst
View File

@ -1,8 +1,8 @@
.. _subcloud-deployment-phases-0ce5f6fbf696:
.. _install-a-subcloud-in-phases-0ce5f6fbf696:
==========================
Subcloud Deployment Phases
==========================
============================
Install a Subcloud in Phases
============================
Subclouds can be deployed using individual phases.
@ -349,7 +349,8 @@ controllers (for example, ``/home/sysadmin/docker-registry-ca-cert.pem``).
.. note::
To modify the kernel using the ansible bootstrap, see :ref:`modify-the-kernel-in-the-cli-39f25220ec1b`
To modify the kernel using the ansible bootstrap, see
:ref:`modify-the-kernel-in-the-cli-39f25220ec1b`.
#. Create the subcloud using :command:`dcmanager`.

135
doc/source/dist_cloud/kubernetes/installing-a-subcloud-using-redfish-platform-management-service.rst
View File

@ -36,6 +36,8 @@ subcloud, the subcloud installation has these phases:
.. _installing-a-subcloud-using-redfish-platform-management-service-ul-g5j-3f3-qjb:
- Remove all removable USB storage devices from subcloud servers before
starting a Redfish remote subcloud install.
- The :command:`software upload` CLI command, executed in the System Controller region,
uploads and stores the ISO to be used to install subclouds in a single
@ -45,8 +47,10 @@ subcloud, the subcloud installation has these phases:
.. note::
- This is required only once and does not have to be done for every
subcloud install.
- The uploading of the Major Release or Patched Major Release load into
the SystemController's ``/opt/dc-vault/software`` directory is
required only once and does not have to be done for every subcloud
install.
:command:`dcmanager` recognizes boot image files ending in ``.iso``
and signature files ending in ``.sig``.
@ -100,68 +104,6 @@ subcloud, the subcloud installation has these phases:
on both controllers (for example, ``/home/sysadmin/docker-registry-ca-cert.pem``).
Controlling the RVMC debug level and automatic serial console log capture
=========================================================================
The optional parameter, ``rvmc_debug_level``, in the subcloud install_values
YAML file, controls the generation of debug logs during |RVMC| installation,
which are then stored in the ansible log files for each subcloud.
**Valid rvmc_debug_levels**
The available ``rvmc_debug_level`` values control the log content as follows.
Note that the log levels increase in verbosity as they increase:
0: Debug logging is disabled (normal log content)
1: Logs operations of each remote install stage, such as RedFish session
open/close, eject/insert image, power on/off host, and more. If the
install_type matches a serial console, then the full serial console log output
is also captured automatically.
2: Logs HTTP request type and URL with corresponding response status.
3: Logs HTTP request headers and payloads, along with Redfish action tracing
logs.
4: Outputs JSON of all command responses.
**Automatic Serial Console capture (for rvmc_debug_level > 0)**
When the ``rvmc_debug_level`` is enabled (``rvmc_debug_level`` > 0), the full serial
console output can be automatically captured, provided the serial console is
configured in the ``install_type`` install value.
.. note:: Capturing the graphical console output is not supported.
The ``install_type`` in the subcloud install_values YAML file must correspond
to one of the serial console types:
0: Standard Controller, Serial Console
2: AIO, Serial Console
.. note::
You can install |v_r8| subclouds with a |this-ver| System Controller.
The |v_r8| subclouds still support menu 4.
Automatic Serial Console capture is based on the global ``CONF.ipmi_capture``
value and the given ``rvmc_debug_level``. The global ``CONF.ipmi_capture``
value defaults to 1, which defers the configuration to the per-subcloud
``rvmc_debug_level`` install value. The ``CONF.ipmi_capture`` can be set in
``/etc/dcmanager/dcmanager.conf`` to override this setting for all subclouds.
CONF.ipmi_capture options:
0: globally disabled
1: enabled based on rvmc_debug_level
2: globally enabled
.. rubric:: |proc|
#. At the subcloud location, physically install the servers and network
@ -299,6 +241,64 @@ CONF.ipmi_capture options:
add` command with the ``subcloud-install-values.yaml`` file containing
the desired ``persistent_size`` value.
**Controlling the RVMC debug level and automatic serial console log capture**
The optional parameter, ``rvmc_debug_level``, in the subcloud install_values
YAML file, controls the generation of debug logs during |RVMC| installation,
which are then stored in the ansible log files for each subcloud.
**Valid rvmc_debug_levels**
The available ``rvmc_debug_level`` values control the log content as follows.
Note that the log levels increase in verbosity as they increase:
0: Debug logging is disabled (normal log content)
1: Logs operations of each remote install stage, such as RedFish session
open/close, eject/insert image, power on/off host, and more. If the
install_type matches a serial console, then the full serial console log output
is also captured automatically.
2: Logs HTTP request type and URL with corresponding response status.
3: Logs HTTP request headers and payloads, along with Redfish action tracing
logs.
4: Outputs JSON of all command responses.
**Automatic Serial Console capture (for ``rvmc_debug_level`` > 1)**
When the ``rvmc_debug_level`` is enabled (``rvmc_debug_level`` > 0), the full serial
console output can be automatically captured, provided the serial console is
configured in the ``install_type`` install value.
.. note:: Capturing graphical console output is not supported.
The ``install_type`` in the subcloud install_values YAML file must correspond
to one of the serial console types:
0: Standard Controller, Serial Console
2: AIO, Serial Console
4: AIO Low-latency, Serial Console
**Automatic Serial Console capture (for ``rvmc_debug_level`` > 1)**
Automatic Serial Console capture is based on the global ``CONF.ipmi_capture``
value and the given ``rvmc_debug_level``. The global ``CONF.ipmi_capture``
value defaults to 1, which defers the configuration to the per-subcloud
``rvmc_debug_level`` install value. The ``CONF.ipmi_capture`` can be set in
``/etc/dcmanager/dcmanager.conf`` to override this setting for all subclouds.
CONF.ipmi_capture options:
0: globally disabled
1: enabled based on rvmc_debug_level
2: globally enabled
#. At the system controller, create a
``/home/sysadmin/subcloud-bootstrap-values.yaml`` overrides file for the
subcloud.
@ -437,9 +437,10 @@ CONF.ipmi_capture options:
.. note::
To modify the kernel using the ansible bootstrap, see :ref:`modify-the-kernel-in-the-cli-39f25220ec1b`
To modify the kernel using the ansible bootstrap, see
:ref:`modify-the-kernel-in-the-cli-39f25220ec1b`.
#. Add the subcloud using dcmanager.
#. Add/Install the subcloud using dcmanager.
When calling the :command:`subcloud add` command, specify the install
values, bootstrap values and the subcloud's sysadmin password.
@ -521,7 +522,7 @@ CONF.ipmi_capture options:
.. code-block:: none
controller-0:/home/sysadmin# tail /var/log/dcmanager/ansible/subcloud_playbook_output.log
controller-0:/home/sysadmin# tail -f /var/log/dcmanager/ansible/subcloud_playbook_output.log
k8s.gcr.io: {password: secret, url: null}
quay.io: {password: secret, url: null}
)

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

@ -13,7 +13,7 @@ When a subcloud is created it is automatically added to the 'Default' subcloud
group, unless the group is specified. Subclouds can be associated with a
particular group when they are created, and that association can be changed to
a different subcloud group, if required. To create a subcloud group, see,
:ref:`Creating Subcloud Groups <creating-subcloud-groups>`.
:ref:`create-edit-and-delete-subcloud-groups-using-the-cli`.
For example, while creating a strategy, if several subclouds can be upgraded or
updated in parallel, they can be grouped together in a subcloud group that
@ -40,17 +40,12 @@ or firmware updates, see:
- To create an upgrade orchestration strategy use the :command:`dcmanager
upgrade-strategy create` command.
.. xbooklink For more information see, :ref:`Distributed
Upgrade Orchestration Process Using the CLI
<distributed-software-deploy-orchestration-process-using-the-cli>`.
For more information see,
:ref:`deploy-software-releases-using-the-cli-1ea02eb230e5`.
- To create an update (patch) orchestration strategy use the
:command:`dcmanager patch-strategy create` command.
.. xbooklink For more information see,
:ref:`Creating an Update Strategy for Distributed Cloud Update Orchestration
<creating-an-update-strategy-for-distributed-cloud-update-orchestration>`.
- To create a firmware update orchestration strategy use the
:command:`dcmanager fw-update-strategy create` command.
@ -60,6 +55,6 @@ or firmware updates, see:
.. seealso::
:ref:`creating-subcloud-groups`
:ref:`create-edit-and-delete-subcloud-groups-using-the-cli`
:ref:`orchestration-strategy-using-subcloud-groups`

131
doc/source/dist_cloud/kubernetes/prestage-subcloud-orchestration-eb516473582f.rst → doc/source/dist_cloud/kubernetes/orchestrate-subcloud-prestage-using-the-cli-eb516473582f.rst
View File

@ -1,14 +1,32 @@
.. _prestage-subcloud-orchestration-eb516473582f:
.. _orchestrate-subcloud-prestage-using-the-cli-eb516473582f:
===============================
Prestage Subcloud Orchestration
===============================
===========================================
Orchestrate Subcloud Prestage Using the CLI
===========================================
This section describes the prestage strategy for a single subcloud, default
subcloud group or a specific subcloud group.
This section describes the prestage strategy for a single subcloud, all
subclouds or a specific subcloud group.
.. rubric:: |prereq|
There are two types of subcloud prestage:
- **Prestage for software deployment** occurs when the subcloud is running an
older software than the system controller during prestaging. This prestage
transfers software update(s) and container images to the subcloud while
preparing for new software deployment. The prestaged data is stored in
various locations on the subcloud. For example, metadata is stored in
``/opt/software/<sw-version>`` and new images are added to the local docker
registry.
- **Prestage for install** occurs when the subcloud is running the same or older
software than the system controller during prestaging. This prestage
transfers the entire platform software and container images of the
specified release while preparing for the subcloud redeployment. This is
used if the subcloud needs to be reinstalled and restored to a specific
release. The prestaged data is stored in the subcloud persistent
filesystem ``/opt/platform-backup/<sw-version>``.
For more information on prerequisites for prestage upgrade and reinstall, see
:ref:`prestage-a-subcloud-using-dcmanager-df756866163f`.
@ -27,15 +45,15 @@ For more information on prerequisites for prestage upgrade and reinstall, see
#. Create a prestage strategy.
Prestage strategy can be created for a single subcloud, the default
subcloud group (all subclouds), or a specific subcloud group.
Prestage strategy can be created for a single subcloud, all subclouds, or a
specific subcloud group.
To create a prestage strategy for a specific subcloud, use the following
command:
.. parsed-literal::
[sysadmin@controller-0 ~(keystone_admin)]$ dcmanager prestage-strategy create --for-install --release nn.nn subcloud7
~(keystone_admin)]$ dcmanager prestage-strategy create --for-install --release nn.nn subcloud7
Enter the sysadmin password for the subcloud:
Re-enter sysadmin password to confirm:
+--------------------------+-----------------------------+
@ -52,12 +70,15 @@ For more information on prerequisites for prestage upgrade and reinstall, see
+--------------------------+-----------------------------+
To create a prestage strategy for the default subcloud group, use the
following command:
.. note::
``--release`` nn.nn specifies only the major release version.
To create a prestage strategy for all subclouds, use the following command:
.. parsed-literal::
[sysadmin@controller-0 ~(keystone_admin)]$ dcmanager prestage-strategy create --for-sw-deploy
~(keystone_admin)]$ dcmanager prestage-strategy create --for-sw-deploy
Enter the sysadmin password for the subcloud:
Re-enter sysadmin password to confirm:
+--------------------------+-----------------------------+
@ -130,23 +151,63 @@ For more information on prerequisites for prestage upgrade and reinstall, see
#. Monitor the progress of the strategy.
.. code-block:: none
- The overall status of the strategy can be viewed with the following
command:
~(keystone_admin)]$ dcmanager strategy-step list
.. code-block:: none
+-----------+-------+---------------------+---------+----------------------------+-------------+
| cloud | stage | state | details | started_at | finished_at |
+-----------+-------+---------------------+---------+----------------------------+-------------+
| subcloud1 | 1 | prestaging-packages | | 2202-03-22 18:55:11.523970 | None |
+-----------+-------+---------------------+---------+----------------------------+-------------+
~(keystone_admin)]$ dcmanager prestage-strategy show
+---------------------------+----------------------------+
| Field | Value |
+---------------------------+----------------------------+
| strategy type | prestage |
| subcloud apply type | None |
| max parallel subclouds | 2 |
| stop on failure | False |
| prestage software version | 24.09 |
| state | complete |
| created_at | 2025-01-21 20:27:05.649975 |
| updated_at | 2025-01-21 20:30:04.113626 |
+---------------------------+----------------------------+
- To view the progress of each strategy step, use the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-step list
+-----------+-------+---------------------+---------+----------------------------+-------------+
| cloud | stage | state | details | started_at | finished_at |
+-----------+-------+---------------------+---------+----------------------------+-------------+
| subcloud1 | 1 | prestaging-packages | | 2202-03-22 18:55:11.523970 | None |
+-----------+-------+---------------------+---------+----------------------------+-------------+
#. (Optional) Abort the strategy, if required.
The abort command can be used to abort the prestage orchestration strategy
after the current step of the currently applying state is completed.
.. code-block:: none
~(keystone_admin)]$ dcmanager prestage-strategy abort
+---------------------------+----------------------------+
| Field | Value |
+---------------------------+----------------------------+
| strategy type | prestage |
| subcloud apply type | None |
| max parallel subclouds | 2 |
| stop on failure | False |
| prestage software version | 24.09 |
| state | abort requested |
| created_at | 2025-01-21T20:27:05.649975 |
| updated_at | 2025-01-21T20:27:31.917127 |
+---------------------------+----------------------------+
#. Delete the strategy.
Once the strategy status is either "complete", "aborted" or "failed", the
strategy can be deleted with the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager prestage-strategy delete
@ -169,31 +230,23 @@ Troubleshoot Subcloud Prestage Orchestration
If an orchestrated prestage fails for a subcloud, check the log specified in
the error message for reasons of failure. After the issue has been resolved,
prestage can be retried using one of the following options:
prestage can be retried using one of the following methods:
.. rubric:: |proc|
- Prestage each failed subcloud individually.
- Run :command:`dcmanager subcloud prestage` command on the failed subcloud.
Use the dcmanager subcloud prestage command on the failed subclouds. See
:ref:`prestage-a-subcloud-using-dcmanager-df756866163f` for more
information.
- Create a subcloud group, for example, ``prestage-retry``, add the failed
subcloud(s) to group ``prestage-retry``, and finally create and apply the
prestage strategy for the group.
- Use prestage orchestration to prestage all failed subclouds.
Create a subcloud group, for example, prestage-retry, add the failed
subcloud(s) to group prestage-retry, and finally create and apply the
prestage strategy to the group, following the procedure described on this
page.
.. warning::
Do not retry orchestration with an existing group unless the subclouds
that have been successfully prestaged are removed from the group.
Otherwise, prestage will be repeated for ALL subclouds in the group.
For more information on the following, see
:ref:`prestage-a-subcloud-using-dcmanager-df756866163f`
- Upload Prestage Image List
- Single Subcloud Prestage
- Rerun Subcloud Prestage
- Verify Subcloud Prestage
- Verifying Usage of Prestaged Data
Otherwise, prestage will be repeated for ALL subclouds in the group.

161
doc/source/dist_cloud/kubernetes/orchestrate-subcloud-prestage-using-the-horizon-dashboard-bdc02df7a2b2.rst Normal file
View File

@ -0,0 +1,161 @@
.. WARNING: Add no lines of text between the label immediately following
.. and the title.
.. _orchestrate-subcloud-prestage-using-the-horizon-dashboard-bdc02df7a2b2:
=========================================================
Orchestrate Subcloud Prestage Using the Horizon Dashboard
=========================================================
This section describes the prestage strategy for a single subcloud, all
subclouds or a specific subcloud group using the Horizon Web Interface. If a
CLI is preferred, see
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f`.
.. rubric:: |prereq|
There are two types of subcloud prestage:
- **Prestage for software deployment** occurs when the subcloud is running an
older software than the system controller during prestaging. This prestage
transfers software update(s) and container images to the subcloud while
preparing for new software deployment. The prestaged data is stored in
various locations on the subcloud. For example, metadata is stored in
``/opt/software/<sw-version>`` and new images are added to the local docker
registry.
- **Prestage for install** occurs when the subcloud is running the same or older
software than the system controller during prestaging. This prestage
transfers the entire platform software and container images of the
specified release while preparing for the subcloud redeployment. This is
used if the subcloud needs to be reinstalled and restored to a specific
release. The prestaged data is stored in the subcloud persistent
filesystem ``/opt/platform-backup/<sw-version>``.
For more information on prerequisites for prestage upgrade and reinstall, see
:ref:`prestage-a-subcloud-using-dcmanager-df756866163f`.
.. note::
Any existing strategy must be deleted first as only one type
of strategy can exist at a time.
.. only:: partner
.. include:: /_includes/prestage-subcloud-orchestration-eb516473582f.rest
:start-after: strategy-begin
:end-before: strategy-end
.. rubric:: |proc|
#. Select the SystemController region.
.. image:: figures/system-controller-region.png
#. Select **Distributed Cloud Admin** > **Orchestration**.
#. On the **Orchestration** page, select the **Strategy** tab.
#. Create a prestage strategy.
On the **Strategy** tab, click **Create Strategy**. In the **Create
Strategy** dialog box, select the **Prestage strategy type** and adjust the
settings as needed.
Prestage strategy can be created for a single subcloud, all subclouds, or a
specific subcloud group.
.. image:: figures/create-strategy-prestage.png
To create a prestage strategy for a specific subcloud, in the **Apply to**
dialog box select **Subcloud** and in **Subcloud** dialog box select the
subcloud to apply the strategy.
.. image:: figures/apply-to-subcloud-option.png
To create a prestage strategy for all subclouds, in the **Subcloud** dialog
box select **All Subclouds**.
.. image:: figures/apply-to-all-subclouds.png
To create a prestage strategy for a specific subcloud group, in the **Apply
to** dialog box select **Subcloud Group** and in the **Subcloud Group**
dialog box choose the **Subcloud Group** to apply the strategy.
.. image:: figures/subcloud-group-new.png
**Strategy Type**
Prestage.
**Release**
Release ID.
This option is available when Strategy Type is set to Prestage.
**For Software Deploy**
Default: False.
Prestage for software deploy operations. If not specified, prestaging
is targeted towards full installation.
**Apply to**
Subcloud or Subcloud Group.
**Subcloud**
Select the subcloud name or All Subclouds.
**Subcloud Group**
Select the subcloud group. Available only if you select the **Apply to:
Subcloud Group** option.
**Stop on Failure**
Default: True.
Determines whether update orchestration failure for a subcloud prevents
application to subsequent subclouds.
**Subcloud Apply Type**
Default: Parallel.
This option is available when Subcloud is set to All Subclouds.
Parallel or Serial. Determines whether the subclouds are updated in
parallel or serially.
**Maximum Parallel Subclouds**
Default: 20.
This option is available when Subcloud is set to All Subclouds.
Defines the maximum number of subclouds that the prestage strategy can
process simultaneously. If the **Apply to: Subcloud Group** option is
selected, it will use the ``max_parallel_subclouds`` value of the
subcloud group instead.
**Force**
Default: False.
Skip checking the subcloud for management affecting alarms.
**Syadmin Password**
Sysadmin Password.
.. note::
Unlike other types of orchestration, prestage orchestration requires
sysadmin password as all communications with the subclouds are done
using ansible over the oam network to avoid disruptions to management
traffic.
#. Click **Create Strategy** to confirm the operation.
#. Click on **Apply Strategy** to start the prestaging.
The overall status of the strategy can be viewed on the Steps table.
.. image:: figures/orchestration-strategy-steps-table.png
#. Delete the strategy.
Once the strategy status is either **complete**, **aborted** or **failed**,
the strategy can be deleted clicking on **Delete Strategy**.

20
doc/source/dist_cloud/kubernetes/prestage-a-subcloud-using-dcmanager-df756866163f.rst
View File

@ -11,7 +11,7 @@ be done using the dcmanager CLI. The prestaging reduces the duration of the
subsequent software update or reinstall in the maintenance window.
For information on prestaging a batch of subclouds, see,
:ref:`prestage-subcloud-orchestration-eb516473582f`.
:ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f`.
.. rubric:: |context|
@ -20,9 +20,10 @@ The main steps of this task are:
#. Ensure prestaging prerequisites are met, see :ref:`prestaging-prereqs`.
#. Upload the list of container images to prestage. This step is relevant to
major release software deployment and must be performed after the system
controller has been updated with the new major release. See :ref:`Upload
Prestage Image List <prestaging-image-list>`.
major release software deployment and patch release and must be performed
after the system controller has been updated with the new major release or
patch release. See :ref:`Upload Prestage Image List
<prestaging-image-list>`.
#. Use dcmanager commands to prestage the subcloud(s).
@ -38,7 +39,7 @@ Prestaging Requirements
.. rubric:: |prereq|
Prestaging can be done for a single subcloud or a batch of subclouds via
orchestration. See :ref:`prestage-subcloud-orchestration-eb516473582f`.
orchestration. See :ref:`orchestrate-subcloud-prestage-using-the-cli-eb516473582f`.
There are two types of subcloud prestage:
@ -165,9 +166,8 @@ post major platform update.
|prestage_images | nn.nn_images.lst|
+------------------+-----------------+
Where, the name of the prestage image file can be user defined. However,
it is recommended to use the following format `<software_version>_images.lst`,
for example, `<21.12_images.lst>`.
Where, the name of the prestage image should be in the following format
`<software_version>_images.lst`, for example, `<21.12_images.lst>`.
#. To confirm that the image list has been uploaded, use the following command.
@ -239,6 +239,10 @@ before prestaging.
| prestage_software_version | 22.12 |
+-----------------------------+----------------------------+
.. note::
``--release`` nn.nn specifies only the major release version.
.. code-block::
[sysadmin@controller-0 ~(keystone_admin)]$ dcmanager subcloud prestage --for-install subcloud5

2
doc/source/dist_cloud/kubernetes/rehoming-a-subcloud.rst
View File

@ -30,7 +30,7 @@ controller using the rehoming playbook.
The system controllers and subclouds must run the same software versions. For
rehoming N-1 subclouds to another system controller running N software
release, refer to :ref:`deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b`.
release, refer to :ref:`subclouds-previous-release-management-5e986615cb4b`.
.. note::

2
doc/source/dist_cloud/kubernetes/rehoming-subcloud-with-expired-certificates-00549c4ea6e2.rst
View File

@ -180,6 +180,8 @@ know about the expiration of SSL CA certificates:
| | | 9062a088-8c71-46c6-b194-6a65908f1080 | | .917781 |
+----------+----------------------------------------------------------------------------------------------------------+--------------------------------------+----------+---------------------+
.. Check with security team
The alarm indicates that the certificate has expired. For more information
about the certificate, run ``sudo show-certs.sh``. The following are the two
possible resolutions:

2
doc/source/dist_cloud/kubernetes/reinstalling-a-subcloud-with-redfish-platform-management-service.rst
View File

@ -43,7 +43,7 @@ Executing the dcmanager subcloud redeploy command in the Central Cloud:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud update subcloud1 --install-values\ install-values.yml --bmc-password <password>
~(keystone_admin)]$ dcmanager subcloud update subcloud1 --install-values install-values.yml --bmc-password <password>
For more information on install-values.yml file, see :ref:`Install a
Subcloud Using Redfish Platform Management Service

47
doc/source/dist_cloud/kubernetes/review-software-release-status-for-distributed-cloud-using-horizon-dashboard.rst Normal file
View File

@ -0,0 +1,47 @@
.. dma1558616138777
.. _review-software-release-status-for-distributed-cloud-using-horizon-dashboard:
================================================================================
Review Software Release Status for Distributed Cloud Using the Horizon Dashboard
================================================================================
You can use the Horizon Dashboard to review the status of each software release
stored in the central software release repository as well as software
synchronization status across subclouds. If a CLI is preferred, see
:ref:`review-software-release-status-for-distributed-cloud-using-the-cli`.
.. rubric:: |proc|
#. Select the **SystemController** region.
.. image:: figures/system-controller-region.png
#. Select **Distributed Cloud Admin** \> **Software Management**.
#. On the **Software Management** page, select the **Releases** tab.
.. image:: figures/software-management-system-controller.png
:width: 1000px
.. note::
The Release State indicates whether the release is available, deploying
or deployed. Deployed indicates that the update has been installed on
all hosts of the cloud (Central Cloud in this case).
#. Identify which subclouds are update-current (in-sync).
The software sync status is part of the overall sync status of a subcloud.
To review the synchronization status of subclouds, see
:ref:`monitoring-subclouds-using-horizon`.
.. note::
The sync status is the rolled up sync status of Dc-Cert, Firmware,
Identity, Kube-Rootca, Kubernetes, Platform, and Software sync status.
The Software sync status indicates whether the subcloud’s deployed
releases (both major and patch releases) match that of the Central
Cloud.
.. image:: figures/monitor-subclouds-horizon.png

127
doc/source/dist_cloud/kubernetes/review-software-release-status-for-distributed-cloud-using-the-cli.rst Normal file
View File

@ -0,0 +1,127 @@
.. hxt1558615716368
.. _review-software-release-status-for-distributed-cloud-using-the-cli:
==================================================================
Review Software Release Status for Distributed Cloud Using the CLI
==================================================================
You can use CLI to review the status of each software release stored in the
central software release repository as well as software synchronization status
across the subclouds. If a web interface is preferred, see
:ref:`review-software-release-status-for-distributed-cloud-using-horizon-dashboard`.
.. rubric:: |proc|
.. _reviewing-update-status-for-distributed-cloud-using-the-cli-steps-unordered-d53-dlx-fdb:
- To check the status of software releases in the central software release
repository, use the software list command on the SystemController region.
For example:
.. only:: starlingx
.. code-block:: none
~(keystone_admin)]$ software --os-region-name SystemController list
+---------------------+-------+----------+
| Release | RR | State |
+---------------------+-------+----------+
| starlingx-24.09.0 | True | deployed |
| starlingx-24.09.100 | False | deployed |
+---------------------+-------+----------+
.. only:: partner
.. include:: /_includes/review-software-release-status-for-distributed-cloud-using-the-cli.rest
:start-after: status-update-table-begin
:end-before: status-update-table-end
The **State** column indicates whether the release is unavailable,
available, deploying, or deployed. The **deployed** state indicates that
the release has been installed on all hosts of the cloud (the Central Cloud
in this case). The **unavailable** state indicates that the release and
associated patches are available in the central software release
repository, but they cannot be used for deployment on this cloud.
- To identify which subclouds are update-current (**in-sync**), use the
following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud list
+----+-----------+--------------+--------------------+-------------+
| id | name | management | availability | sync |
+----+-----------+--------------+--------------------+-------------+
| 1 | subcloud1 | managed | online | in-sync |
| 2 | subcloud2 | managed | online | in-sync |
| 3 | subcloud3 | managed | online | out-of-sync |
+----+-----------+--------------+--------------------+-------------+
.. note::
The **sync** status is the rolled up **sync** status of
``dc_cert_sync_status``, ``firmware_sync_status``,
``identity_sync_status``, ``kubernetes_sync_status``,
``kube-rootca_sync_status``, ``platform_sync_status``, and
``software_sync_status``. The ``software_sync_status`` indicates
whether the subcloud's deployed releases (both major and patch
releases) match those of the Central Cloud.
- To see synchronization details for a subcloud:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show subcloud1
+-----------------------------+----------------------------+
| Field | Value |
+-----------------------------+----------------------------+
| id | 1 |
| name | subcloud1 |
| description | None |
| location | None |
| software_version | nn.nn |
| management | managed |
| availability | online |
| deploy_status | complete |
| management_subnet | fd01:82::0/64 |
| management_start_ip | fd01:82::2 |
| management_end_ip | fd01:82::11 |
| management_gateway_ip | fd01:82::1 |
| systemcontroller_gateway_ip | fd01:81::1 |
| group_id | 1 |
| created_at | 2020-07-15 19:23:50.966984 |
| updated_at | 2020-07-17 12:36:28.815655 |
| backup_status | None |
| backup_datetime | None |
| prestage_status | complete |
| prestage_version | 22.12,24.09 |
| dc-cert_sync_status | in-sync |
| firmware_sync_status | in-sync |
| identity_sync_status | in-sync |
| kubernetes_sync_status | out-of-sync |
| kube-rootca_sync_status | in-sync |
| load_sync_status | not-available |
| patching_sync_status | not-available |
| platform_sync_status | in-sync |
| software_sync_status | in-sync |
| region_name | subcloud11 |
+-----------------------------+----------------------------+
.. note::
Prior to software release version |prod-ver|, the major software
release status was presented by load_sync_status attribute and the patch
software release status by ``patching_sync_status`` attribute. Starting
with software release version |prod-ver| and above, both major and minor
software release statuses are presented by a single
``software_sync_status`` attribute.
The ``patching_sync_status`` is only applicable to subclouds running
the previous release (i.e. below |prod-ver|). It indicates whether the
subcloud's deployed patches of the previous release match those of
the Central Cloud.
Both ``patching_sync_status`` and ``load_sync_status`` attributes will
be removed in a future release.

47
doc/source/dist_cloud/kubernetes/reviewing-update-status-for-distributed-cloud-using-horizon.rst
View File

@ -1,47 +0,0 @@
.. dma1558616138777
.. _reviewing-update-status-for-distributed-cloud-using-horizon:
========================================================
Review Update Status for Distributed Cloud Using Horizon
========================================================
You can review updates across the |prod-dc| from the Horizon Web interface.
.. rubric:: |context|
If you prefer, you can use the |CLI|. For more information, see
:ref:`reviewing-update-status-for-distributed-cloud-using-the-cli`.
From Horizon, you can use only the **SystemController** region to
review updates in the central update repository and the update sync status of
subclouds.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Software Management**.
#. On the **Software Management** page, select the **Releases** tab.
.. image:: figures/software-management-system-controller.png
:width: 1000px
.. note::
The Release State indicates whether the release is available, deploying
or deployed. Deployed indicates that the update has been installed on
all hosts of the cloud (SystemController in this case).
#. Check the Update Sync Status of the subclouds.
Update (or Patch) Sync Status is part of the overall Sync status of a
subcloud. To review the synchronization status of subclouds, see
:ref:`monitoring-subclouds-using-horizon`.
.. rubric:: |postreq|
To update the SystemController's central update repository, see
:ref:`uploading-and-applying-updates-to-systemcontroller-using-horizon`.

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

@ -1,90 +0,0 @@
.. hxt1558615716368
.. _reviewing-update-status-for-distributed-cloud-using-the-cli:
========================================================
Review Update Status for Distributed Cloud Using the CLI
========================================================
You can use the CLI to review the updates in the central update repository and
their synchronization status across the subclouds of the |prod-dc|.
.. rubric:: |context|
To use the Horizon Web interface instead, see :ref:`Reviewing Update Status for
Distributed Cloud Using Horizon
<reviewing-update-status-for-distributed-cloud-using-horizon>`.
.. rubric:: |proc|
.. _reviewing-update-status-for-distributed-cloud-using-the-cli-steps-unordered-d53-dlx-fdb:
- To check the status of updates in the central update repository, use the
query option on the SystemController region.
For example:
.. code-block:: none
~(keystone_admin)]$ software --os-region-name SystemController list
+-------------------+-------+----------+
| Release | RR | State |
+-------------------+-------+----------+
| starlingx-24.09.0 | True | deployed |
| starlingx-24.09.1 | False | deployed |
+-------------------+-------+----------+
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
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud list
+----+-----------+--------------+--------------------+-------------+
| id | name | management | availability | sync |
+----+-----------+--------------+--------------------+-------------+
| 1 | subcloud1 | managed | online | in-sync |
| 2 | subcloud2 | managed | online | in-sync |
| 3 | subcloud3 | managed | online | out-of-sync |
+----+-----------+--------------+--------------------+-------------+
.. note::
The **sync** status is the rolled up sync status of
**platform-sync-status**, **identity-sync-status**, and
**software-sync-status**.
- To see synchronization details for a subcloud:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show subcloud1
+-----------------------------+----------------------------+
| Field | Value |
+-----------------------------+----------------------------+
| id | 1 |
| name | subcloud1 |
| description | None |
| location | None |
| software_version | nn.nn |
| management | managed |
| availability | online |
| deploy_status | complete |
| management_subnet | fd01:82::0/64 |
| management_start_ip | fd01:82::2 |
| management_end_ip | fd01:82::11 |
| management_gateway_ip | fd01:82::1 |
| systemcontroller_gateway_ip | fd01:81::1 |
| group_id | 1 |
| created_at | 2020-07-15 19:23:50.966984 |
| updated_at | 2020-07-17 12:36:28.815655 |
| dc-cert_sync_status | in-sync |
| identity_sync_status | in-sync |
| load_sync_status | not-available |
| patching_sync_status | not-available |
| software_sync_status | in-sync |
| platform_sync_status | in-sync |
+-----------------------------+----------------------------+

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

@ -1,45 +0,0 @@
.. ziu1597089603252
.. _robust-error-handling-during-an-orchestrated-upgrade:
=============================================
Error Handling During An Orchestrated Upgrade
=============================================
This section describes the errors you may encounter during an orchestrated
upgrade and the steps you can use to troubleshoot the errors.
.. rubric:: |prereq|
For a successful orchestrated upgrade, ensure the upgrade prerequisites,
procedure, and postrequisites are met.
.. rubric:: |proc|
If a failure occurs, use the following general steps:
.. _robust-error-handling-during-an-orchestrated-upgrade-ol-l5y-mby-qmb:
#. Allow the failed strategy to complete on its own.
#. Check the output using the :command:`dcmanager strategy-step list` command
for failures, if any.
#. 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-software-deploy-orchestration-process-using-the-cli`.
.. note::
Orchestrated upgrade can be retried for a group of failed subclouds that
are still **online** using the :command:`upgrade-strategy create --group
<group-id>` command.
Failed subclouds that are **offline** must be retried one at a time.
.. seealso::
* :ref:`failure-prior-to-the-installation-of-n-plus-1-load-on-a-subcloud`
* :ref:`failure-during-the-installation-or-data-migration-of-n-plus-1-load-on-a-subcloud`

4
doc/source/dist_cloud/kubernetes/shared-configurations.rst
View File

@ -28,11 +28,9 @@ for resources of the Keystone Identity Service (see :ref:`Table 2
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Shared Configuration | Remarks |
+=============================+==============================================================================================================================================================================================================================================================================================================================================================+
| DNS IP addresses | Subclouds use the DNS servers specified at the System Controller. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| **sysadmin** Password | The **sysadmin** password may take up to 10 minutes to sync with the controller. The **sysadmin** password is not modified via the :command:`system` command. It is modified using the regular Linux :command:`passwd` command. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Certificates | Subclouds use the Trusted CA certificates installed on the System Controller using the system ca-certificate-install command. |
| Certificates | Subclouds use the Trusted CA certificates installed on the System Controller. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

34
doc/source/dist_cloud/kubernetes/software-release-deployment-in-distributed-cloud-overview.rst Normal file
View File

@ -0,0 +1,34 @@
.. bkh1558616177792
.. _software-release-deployment-in-distributed-cloud-overview:
=========================================================
Software Release Deployment in Distributed Cloud Overview
=========================================================
You can deploy a new software release on the System Controller then orchestrate
the software deployment across managed subclouds from the System Controller.
A central software release repository exists for each major release on the
System Controller. This is also used to store all patch releases for each
respective major release. All software releases must be uploaded to the System
Controller region i.e. by specifying ``--os-region-name SystemController`` in
the software upload command, so that they will be available for patch
application to both the Central Cloud and the managed subclouds.
When a new subcloud is deployed, it will be bootstrapped with the latest patch
that is available in the central software release repository for the specified
release.
Both major and minor software releases can be viewed, uploaded, deployed and
removed using CLI or Horizon dashboard. The same procedure is used to deploy
both types of software releases. After a new software release, major or minor,
has been uploaded to the central repository; it must be deployed first on the
Central Cloud, then prestaged on the subclouds and finally deployed on the
subclouds. However, the deployment of a major software release requires more
preparation which is described in a separate chapter.
.. note::
For Distributed Cloud, manual updating software of individual subclouds is
not recommended.

188
doc/source/dist_cloud/kubernetes/deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b.rst → doc/source/dist_cloud/kubernetes/subclouds-previous-release-management-5e986615cb4b.rst
View File

@ -1,15 +1,19 @@
.. _deploy-restore-and-manage-subclouds-of-previous-release-5e986615cb4b:
.. _subclouds-previous-release-management-5e986615cb4b:
=========================================================
Deploy, Restore, and Manage Subclouds of Previous Release
=========================================================
===========================================
Subclouds Previous Major Release Management
===========================================
.. only:: starlingx
Starting with |prod| |v_r8| and subsequent releases, you can now install,
restore, and manage subclouds of the previous software release. This
capability can be used to revert to the previous release when an unforeseen
issue is encountered during a subcloud upgrade or deployment.
Starting with |prod| |v_r8| and subsequent major releases, you can now
install, restore, and manage subclouds of the previous major software
release from a SystemController running the current major software release.
This capability can be used to revert to the previous release (i.e. major
release, or patched major release) when an unforeseen issue is encountered
during a subcloud upgrade or deployment, or to continue to manage (e.g.
update/patch, rehome, etc.) subclouds of the previous major release that
have not yet been upgraded.
.. only:: partner
@ -30,7 +34,8 @@ Deploy, Restore, and Manage Subclouds of Previous Release
.. rubric:: |context|
This section describes the steps for deploying, restoring, and managing
subclouds of the previous release.
subclouds of the previous major release from a SystemController running the
current major software release.
**Operations Supported for Subclouds of Previous Release**
@ -46,17 +51,25 @@ subclouds of the previous release.
- Orchestrated subcloud prestage (multiple subclouds)
- Orchestrated subcloud sw-deploy of major release or patched major release
(upgrade) (multiple subclouds)
- Orchestrated subcloud patch of major release (update/patch) (multiple
subclouds)
- Subcloud rehome
- Deploy files upload/show
.. note::
After deployment, subclouds running the previous release can be managed,
After deployment, subclouds running the previous major release can be managed,
unmanaged, audited, updated, upgraded, or deleted in the same way as
subclouds running the current release.
**Operations with Limited Support for Subclouds of Previous Release**
For more details, see :ref:`orchestrated-subcloud-patch-of-major-release`.
**Operations with Limited Support for Subclouds of Previous Major Release**
- Subcloud Backup
@ -105,14 +118,15 @@ subclouds of the previous release.
such as, ``Not enough free space in /opt/platform-backup. It has
2010876KiB. It needs at least 3558912KiB``.
- Orchestrated subcloud patch of major release (update/patch) (multiple
subclouds)
**Operations Not Supported for Subclouds of Previous Release**
- Orchestrated subcloud kubernetes upgrade
- Orchestrated subcloud firmware update
- Orchestrated subcloud patching
- Admin network configuration
@ -121,21 +135,32 @@ subclouds of the previous release.
To support subcloud install or subcloud restore to either the current (N) or
previous (N-1) release, ensure that the following prerequisites are met:
- The N load (pre-patched ISO) containing this capability must be uploaded to
the system controller. The ISO uploaded via :command:`software upload` should
be at the same patch level as the system controller. This requirement ensures
that the subcloud boot image is aligned with the patch level of the load to
be installed on the subcloud.
- The N load (pre-patched ISO) containing this capability must be imported to
the system controller using the :command:`software --os-region-name SystemController upload`
command. The ISO imported should be at the same patch level as the system
controller. This requirement ensures that the subcloud boot image is
aligned with the patch level of the load to be installed on the subcloud.
.. note::
Each time a new patch is applied on the system controller, it is
necessary to re-import the new pre-patched ISO containing the same
necessary to re-upload the new pre-patched ISO containing the same
patch(es).
- The only latest uploaded ISO (i.e. GA version of ISO or Patched ISO) for
each major release is kept at the DC SystemController.
- The N-1 load (pre-patched ISO) must be imported to the system controller
To display latest uploaded ISO for a particular major release, at the DC
SystemController run:
.. code-block:: none
~(keystone_admin)]$ software list
.. _n-1-load-uploaded-system-controller:
- The N-1 load (pre-patched ISO) must be uploaded to the system controller
using the the following command:
.. code-block:: none
@ -195,42 +220,45 @@ previous (N-1) release, ensure that the following prerequisites are met:
Upload Deploy/Prestage files
----------------------------
Use the :command:`dcmanager subcloud-deploy upload` command with the
Use the :command:`dcmanager subcloud deploy upload` command with the
``--release`` option to upload deploy or prestage artifacts for a specific
release version.
major release version.
.. rubric:: |proc|
#. To upload deploy files use :command:`dcmanager subcloud-deploy upload`
#. To upload deploy files use :command:`dcmanager subcloud deploy upload`
command with ``--deploy-playbook``, ``--deploy-chart`` and
``--deploy-overrides`` options. The following command uploads deploy files
for |prod| |v_r8|:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-deploy upload
~(keystone_admin)]$ dcmanager subcloud deploy upload
--deploy-playbook <deployment-manager-yaml-file>
--deploy-chart <deployment-manager-chart-tarball>
--deploy-overrides <deployment-manager-overrides-subcloud-yaml-file>
--release <xx.xx>
Where, <xx.xx> is the |prod| |v_r8| version.
Where, <xx.xx> is the |prod| |v_r8| major version.
.. note::
The deploy files for N-1 release are automatically uploaded when
running the :command:`software --os-region-name SystemController upload
<bootimage>.iso <bootimage>.sig` command. It is not mandatory to upload deploy
files for the N release. If the deploy files are not uploaded, the
software will use the default deploy files included in the active load.
Run the :command:`software --os-region-name SystemController upload
<bootimage>.iso <bootimage>.sig` command to automatically upload deploy
files for N-1 release.
#. To upload prestage images list use :command:`dcmanager subcloud-deploy
It is not mandatory to upload deploy files for the N release. If the
deploy files are not uploaded, the software will use the default deploy
files included in the active load of the SystemController (running the
N release).
#. To upload prestage images list use :command:`dcmanager subcloud deploy
upload` command with ``--prestage-images`` option. The following command
uploads the images list for |prod| |v_r6|:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-deploy upload --prestage-images <images-list-file> --release <xx.xx>
~(keystone_admin)]$ dcmanager subcloud deploy upload --prestage-images <images-list-file> --release <xx.xx>
Where, <xx.xx> is the |prod| |v_r6| version.
@ -239,20 +267,20 @@ release version.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-deploy show
--release <previous_or_current_release_number>
~(keystone_admin)]$ dcmanager subcloud deploy show
--release <previous_or_current_major_release_number>
.. note::
If the ``--release`` option is not specified, the deploy/images list files
are uploaded or shown for the current release.
are uploaded or shown for the current major release.
Deploy a New Subcloud
---------------------
Use the :command:`dcmanager subcloud add` command with the ``--release`` option
to deploy a subcloud with the specified release version.
to deploy a subcloud with the specified major release version.
To initiate the deployment of a subcloud running |prod| release |v_r6|, ensure
that the required |prod| |v_r6| deploy files are uploaded, and that the
@ -277,12 +305,12 @@ run the following command:
--sysadmin-password <sysadmin_password>
--release <xx.xx>
Where, <xx.xx> is the |prod| |v_r6| version.
Where, <xx.xx> is the |prod| |v_r6| major version.
.. note::
If the ``--release`` option is not specified, the subcloud will be deployed
to the current release of the system controller.
to the current major release of the system controller.
.. warning::
@ -292,15 +320,22 @@ Where, <xx.xx> is the |prod| |v_r6| version.
to exclude `software_version` from the subcloud's ``install-values.yaml``
configuration to prevent potential conflicts.
.. note::
To deploy a patched ISO, you must have previsouly updated the
SystemController with the current ISO for the N-1 major release, see
:ref:`prerequisite <n-1-load-uploaded-system-controller>`.
Restore a Subcloud
------------------
.. note::
If a subcloud needs to be reverted to the previous release after an upgrade
failure, it is recommended to take a backup of the subcloud before the
upgrade using the :command:`dcmanager subcloud-backup create` command. For
additional information, see
If a subcloud needs to be reverted to the previous major release after an
upgrade failure, it is recommended to take a backup of the subcloud before
the upgrade using the :command:`dcmanager subcloud-backup create` command.
For additional information, see
:ref:`backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42`.
.. note::
@ -308,8 +343,10 @@ Restore a Subcloud
A subcloud cannot be restored from a backup that was taken before it was
deleted and redeployed.
To restore a subcloud from a backup of the previous release, ensure that the
pre-patched ISO has been imported into the DC vault and use the
To restore a subcloud from a backup of the previous major release, ensure that
the pre-patched ISO for the previous major release, that aligns with the backup
being restored, has been uploaded at the SystemController (i.e. see line
:ref:`prerequisite <n-1-load-uploaded-system-controller>`), and use the
:command:`dcmanager subcloud-backup restore` command with the ``--release``
option.
@ -317,7 +354,7 @@ option.
~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud <subcloud> --with-install --sysadmin-password <sysadmin_password> --release <xx.xx>
Where, <xx.xx> is the |prod| |v_r6| version.
Where, <xx.xx> is the |prod| |v_r6| major version.
For additional information about the restore, refer to "Restore a single subcloud"
section in
@ -326,8 +363,8 @@ section in
.. note::
If the ``--release`` option is not specified, the subcloud will be
installed to the current release and restored from a backup of the current
release.
installed to the current major release and restored from a backup of the
current release.
.. warning::
@ -338,9 +375,9 @@ section in
Delete a Subcloud Backup
------------------------
To delete a subcloud backup of a particular release, use the
:command:`dcmanager subcloud-backup delete` command with the release number
specified. For more information, see
To delete a subcloud backup of a particular major release, use the
:command:`dcmanager subcloud-backup delete` command with the major release
number specified. For more information, see
:ref:`delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd`.
@ -351,7 +388,7 @@ specified. For more information, see
~(keystone_admin)]$ dcmanager subcloud-backup delete <xx.xx> --subcloud
Where, <xx.xx> is the |prod| |v_r8| version.
Where, <xx.xx> is the |prod| |v_r8| major version.
- To delete |prod| |v_r6| backup data from local storage, use the following
@ -361,7 +398,7 @@ specified. For more information, see
~(keystone_admin)]$ dcmanager subcloud-backup delete <xx.xx> --local-only --subcloud --sysadmin-password <sysadmin_password>
Where, <xx.xx> is the |prod| |v_r6| version.
Where, <xx.xx> is the |prod| |v_r6| major version.
Prestage a Subcloud
@ -399,7 +436,7 @@ or both of the following steps:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-deploy upload --prestage-images <nn.nn_images.lst>
~(keystone_admin)]$ dcmanager subcloud deploy upload --prestage-images <nn.nn_images.lst>
.. table:: Table 1. Container Images Prestage Behavior for |prod| |v_r8| and higher
@ -440,7 +477,7 @@ one or both of the following steps:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-deploy upload --prestage-images --release <N-1-software-version> <nn.nn_images.lst>
~(keystone_admin)]$ dcmanager subcloud deploy upload --prestage-images --release <N-1-major-software-version> <nn.nn_images.lst>
.. table:: Table 2. Container Images Prestage Behavior for |prod| |v_r6|
:widths: auto
@ -467,7 +504,7 @@ one or both of the following steps:
~(keystone_admin)]$ dcmanager subcloud prestage --for-install --sysadmin-password <sysadmin-password> --release <xx.xx> <subcloud-name-or-id>
Where, <xx.xx> is the |prod| |v_r6| version.
Where, <xx.xx> is the |prod| |v_r6| major version.
- To prestage a group of subclouds use :command:`dcmanager prestage-strategy`
related commands. The following commands can be used to prestage a group of
@ -487,7 +524,46 @@ one or both of the following steps:
~(keystone_admin)]$ dcmanager prestage-strategy apply
Where, <xx.xx> is the |prod| |v_r8| version.
Where, <xx.xx> is the |prod| |v_r8| major version.
.. _orchestrated-subcloud-patch-of-major-release:
Orchestrated subcloud patch of major release
--------------------------------------------
To update/patch a subcloud of a previous major release, use the legacy patch
orchestration :command:`dcmanager patch-strategy create` command with the patch
ID specified.
#. Prestage the patch first using the ``--upload-only`` parameter.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy create --upload-only <patch-file>
#. Create a patch strategy for specific patch, using the following command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy create <patch_id>
#. Apply the patch strategy.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy apply
#. Delete a patch strategy for specific patch, using the following command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy delete
.. note::
Upgrading a subcloud from a previous release sometimes requires a patch to
enable Software Deploy orchestration.
Rehome a Subcloud
-----------------

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

@ -1,53 +0,0 @@
.. bkh1558616177792
.. _update-management-for-distributed-cloud:
=======================================
Update Management for Distributed Cloud
=======================================
You can apply software updates (also known as 'patches') to the Central Cloud
and subclouds from the System Controller.
A central update repository on the Central Cloud is introduced for |prod-dc|.
This is used to store all updates (patches) so that unmanaged subclouds can
be synchronized with any required updates when they are brought into a managed
state.
To ensure the integrity of the |prod-dc| system, all updating must be done from
the Central Cloud.
.. caution::
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:`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.
You can use the Horizon Web interface or the command line interface to manage
updates. The workflow for patching is as follows:
.. _update-management-for-distributed-cloud-ul-pz2-gwd-rdb:
#. Review the update status of the systems in the |prod-dc|.
See :ref:`reviewing-update-status-for-distributed-cloud-using-horizon`.
#. Upload and apply any required updates to the System Controller. This adds
them to a Central Update Repository, making them available to the
SystemController and all subclouds.
See :ref:`uploading-and-applying-updates-to-systemcontroller-using-horizon`.
#. Update the Central Cloud's RegionOne and all subclouds with the updates
using update orchestration.
See :ref:`update-orchestration-of-central-clouds-regionone-and-subclouds`.
.. note::
For |prod-dc|, manual updating of individual subclouds is not recommended.

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

@ -1,409 +0,0 @@
.. fql1558615252466
.. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli:
===============================================
Update Orchestration of Subclouds using the CLI
===============================================
For |prod-dc| update orchestration, you can use the :command:`dcmanager`
commands from the command line interface. These are similar to the
:command:`sw-manager` commands used to define and execute update strategies on
non-distributed systems, or on the SystemController RegionOne.
.. contents:: |minitoc|
:local:
:depth: 1
To use the Horizon Web interface instead, see
:ref:`update-orchestration-of-central-clouds-regionone-and-subclouds`.
.. note::
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, 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:
-----------------------
Patch Strategy Settings
-----------------------
The update strategy for a |prod-dc| system controls how updates are applied to
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
parallel, or serially.
If this is not specified using the |CLI|, the values for
:command:`subcloud_update_type` defined for each subcloud group will be
used by default.
**maximum parallel subclouds**
Sets the maximum number of subclouds that can be updated in parallel (default 20).
If this is not specified using the |CLI|, the values for
:command:`max_parallel_subclouds` defined for each subcloud group will be
used by default.
**stop on failure**
true (default) or false — determines whether update orchestration failure
for a subcloud prevents application to subsequent subclouds.
**upload only**
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 an update strategy, use the :command:`patch-strategy create <patch_id>`
command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy create <patch_id> \
[--subcloud-apply-type <type>] \
[–-max-parallel-subclouds <i>] \
[–-stop-on-failure <level>] \
[--upload-only] \
[--group group] \
[<subcloud>]
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy create <patch_id> --group 10
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| subcloud apply type | parallel |
| max parallel subclouds | 10 |
| stop on failure | False |
| state | initial |
| created_at | 2021-01-07T14:54:58.634476 |
| updated_at | None |
+------------------------+----------------------------+
.. note::
You can optionally pass the name or ID of a subcloud group to the
:command:`patch-strategy create` command. This results in a strategy
that is applied only to all subclouds in the specified group. The
subcloud group values are used for subcloud apply type and max parallel
subclouds parameters.
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.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy create --upload-only
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| strategy type | patch |
| subcloud apply type | None |
| max parallel subclouds | None |
| stop on failure | False |
| upload only | True |
| state | initial |
| created_at | 2023-03-08T13:58:50.130629 |
| updated_at | None |
+------------------------+----------------------------+
.. note::
This is useful to reduce the total time it takes to run the
orchestration during a system maintenance window by enabling the user
to upload the patches to the subclouds before the system maintenance
window.
If the ``--upload-only`` option is used, the ``updating patches`` state
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.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy show
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| subcloud apply type | parallel |
| max parallel subclouds | 20 |
| stop on failure | False |
| state | initial |
| created_at | 2018-02-02T14:42:13.822499 |
| updated_at | None |
+------------------------+----------------------------+
.. note::
A value of **None** for **subcloud apply type**, and **max parallel
subclouds** indicates that subcloud group values are being used.
- To apply the update strategy, use the :command:`patch-strategy apply` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy apply
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| subcloud apply type | parallel |
| max parallel subclouds | 20 |
| stop on failure | False |
| state | applying |
| created_at | 2018-02-02T14:42:13.822499 |
| updated_at | 2018-02-02T14:42:19.376688 |
+------------------------+----------------------------+
- To show the step currently being performed on each of the subclouds, use
the :command:`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 | applying... | apply phase is 66% complete | 2018-03-13 14:16:02.457588 | None |
| subcloud-4 | 1 | applying... | apply phase is 83% complete | 2018-03-13 14:16:02.463213 | None |
| subcloud-5 | 1 | finishing | | 2018-03-13 14:16:02.473669 | None |
| subcloud-6 | 1 | applying... | apply phase is 66% complete | 2018-03-13 14:16:02.483422 | None |
+------------------+-------+-------------+-----------------------------+----------------------------+----------------------------+
- To show the step currently being performed on a subcloud, use the
:command:`strategy-step show` <subcloud> command.
.. code-block:: none
~(keystone_admin)]$ dcmanager strategy-step show <subcloud>
- To abort the current update orchestration operation, use the
:command:`patch-strategy abort` command.
.. note::
The :command:`dcmanager patch-strategy abort` command completes the
current updating stage before aborting, to prevent hosts from being
left in a locked state requiring manual intervention.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy abort
- To delete a update strategy, use the :command:`patch-strategy delete` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy delete
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| subcloud apply type | parallel |
| max parallel subclouds | 20 |
| stop on failure | False |
| state | deleting |
| created_at | 2018-03-23T20:04:50.992444 |
| updated_at | 2018-03-23T20:05:14.157352 |
+------------------------+----------------------------+
.. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli-section-N1022D-N10029-N10001:
------------------------------------
Configuration for Specific Subclouds
------------------------------------
To determine how updates are applied to the nodes on each subcloud, the update
strategy refers to separate configuration settings. The following settings are
applied by default:
.. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli-ul-sgb-p34-gdb:
- storage apply type: parallel
- worker apply type: parallel
- max parallel workers: 10
- alarm restriction type: relaxed
- default instance action: migrate
To update the default values, use the :command:`dcmanager patch-strategy-config
update` command. You can also use this command to configure custom behavior for
individual subclouds.
.. note::
Since re-location is not possible on a single-node |prod| Simplex system,
you must change the configuration to set default_instance_action to
stop-start.
.. _update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli-ul-xfb-bfz-fdb:
- To list the default update strategy and any custom configurations
configured for individual subclouds, use the :command:`patch-strategy-config
list` command.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy-config list
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
| cloud | storage apply type | worker apply type | max parallel workers | alarm restriction type | default instance |
| | | | | | action |
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
| all clouds default | parallel | parallel | 10 | relaxed | migrate |
| subcloud-6 | parallel | parallel | 2 | relaxed | stop-start |
+--------------------+--------------------+--------------------+-----------------------+------------------------+------------------+
- To show the configuration settings applicable to all subclouds by default,
use the :command:`patch-strategy-config show` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy-config show
+-------------------------+--------------------+
| Field | Value |
+-------------------------+--------------------+
| cloud | all clouds default |
| storage apply type | parallel |
| worker apply type | parallel |
| max parallel workers | 10 |
| alarm restriction type | relaxed |
| default instance action | migrate |
| created_at | None |
| updated_at | None |
+-------------------------+--------------------+
- To update the settings, or to create a custom configuration for a subcloud,
use the :command:`patch-strategy-config update` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy-config update \
\
–-storage-apply-type <type> \
–-worker-apply-type <type> \
–-max-parallel-workers <i> \
–-alarm-restriction-type <level> \
–-default-instance-action <action> \
[<subcloud_name>]
where
**storage apply type**
parallel or serial — determines whether storage nodes are updated in
parallel or serially.
**worker apply type**
parallel or serial — determines whether worker nodes are updated in
parallel or serially.
**max parallel workers**
Set the maximum number of worker nodes that can be updated in parallel.
**alarm restriction type**
relaxed or strict — determines whether the orchestration is aborted for
alarms that are not management-affecting.
.. For more information, refer to |updates-doc|: :ref:`configuring-update-orchestration`.
**default instance action**
.. note::
This parameter is only applicable to hosted application VMs with
the |prefix|-openstack application.
migrate or stop-start — determines whether hosted application VMs are
migrated or stopped and restarted when a worker host is upgraded.
**subcloud_name**
The name of the subcloud to use the custom strategy. If this omitted,
the default update strategy is updated.
.. note::
You must specify all of the settings.
- To show the configuration settings for a subcloud, use the
:command:`patch-strategy-config show` <subcloud> command.
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy-config show [<name>]
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager patch-strategy-config show subcloud-6
+-------------------------+----------------------------+
| Field | Value |
+-------------------------+----------------------------+
| cloud | subcloud-6 |
| storage apply type | parallel |
| worker apply type | parallel |
| max parallel workers | 2 |
| alarm restriction type | relaxed |
| default instance action | stop-start |
| created_at | 2018-03-12 20:08:48.917866 |
| updated_at | None |
+-------------------------+----------------------------+
If custom configuration settings have not been created for the subcloud,
the following message is displayed:
.. code-block:: none
ERROR (app) No options found for Subcloud with id 1, defaults will be used.

111
doc/source/dist_cloud/kubernetes/update-orchestration-of-central-clouds-regionone-and-subclouds.rst
View File

@ -1,111 +0,0 @@
.. mmg1558615549438
.. _update-orchestration-of-central-clouds-regionone-and-subclouds:
=================================
Update Orchestration of Subclouds
=================================
You can use update orchestration to automate software updates across all
subclouds in the |prod-dc|.
You can use the Horizon Web interface or the CLI. To use the CLI, see
:ref:`update-orchestration-of-central-clouds-regionone-and-subclouds-using-the-cli`.
.. note::
Patch orchestration is the recommended method for updating software on a
|prod-dc| system. Do not update individual subclouds manually.
To use update orchestration, complete the following workflow:
.. _update-orchestration-of-central-clouds-regionone-and-subclouds-ul-ttl-gc3-4db:
#. Ensure that the required updates are uploaded and applied to the
SystemController / central update repository.
For more information, see
:ref:`uploading-and-applying-updates-to-systemcontroller-using-horizon`.
#. Update the RegionOne, for more information see
:ref:`uploading-and-applying-updates-to-systemcontroller-using-horizon-update-the-regionone`.
#. Create an update strategy for the |prod-dc| update orchestration.
See :ref:`creating-an-update-strategy-for-distributed-cloud-update-orchestration`.
#. Optionally, customize the configuration settings used by the update strategy.
The update strategy is applied to all subclouds using default configuration
settings. You can change these settings, and you can create custom settings
for individual subclouds. For more information, see
:ref:`customizing-the-update-configuration-for-distributed-cloud-update-orchestration`.
#. Apply the strategy for the |prod-dc| update orchestration.
See :ref:`applying-the-update-strategy-for-distributed-cloud`.
As each subcloud is updated, it moves through the following states:
- For software deployment of a patch:
**Initial**
The update has not started.
**Precheck**
Subcloud alarm status is being checked for management-affecting
alarms.
**Create VIM strategy**
The strategy is being created in the subcloud.
**Apply VIM strategy**
The strategy is being applied in the subcloud.
**Finish strategy**
Updates that are no longer required are being deleted.
Updates that require committing are being committed.
**Complete**
Updating has been completed successfully.
- For software deployment of a major release (upgrade):
**Initial**
The update has not started.
**Precheck**
Subcloud alarm status is being checked for management-affecting
alarms.
**Install license**
Installing release license.
**Create VIM strategy**
The strategy is being created in the subcloud.
**Apply VIM strategy**
The strategy is being applied in the subcloud.
**Finish strategy**
Updates that are no longer required are being deleted.
Updates that require committing are being committed.
**Complete**
Updating has been completed successfully.
During this process, alarms **900.001** and **900.101** are raised
temporarily.
.. seealso::
:ref:`creating-an-update-strategy-for-distributed-cloud-update-orchestration`
:ref:`customizing-the-update-configuration-for-distributed-cloud-update-orchestration`
:ref:`applying-the-update-strategy-for-distributed-cloud`

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

@ -1,87 +0,0 @@
.. gjf1592841770001
.. _upgrade-management-overview:
===========================
Upgrade Management Overview
===========================
You can upgrade |prod|'s |prod-dc|'s System Controller, and subclouds with a new
release of |prod| software.
.. rubric:: |context|
.. note::
Backup all yaml files that are updated using the Redfish Platform
Management service. For more information, see
:ref:`installing-a-subcloud-using-redfish-platform-management-service`.
For information on back up and restore, see :ref:`backing-up-starlingx-system-data`.
You can use the |CLI| to manage upgrades. The workflow for upgrades is as
follows:
.. _upgrade-management-overview-ol-uqv-p24-3mb:
#. To upgrade the |prod-dc| system, you must first upgrade the
System Controller. See :ref:`upgrading-the-systemcontroller-using-the-cli`.
#. Use |prod-dc| Upgrade Orchestration to upgrade the subclouds. See
: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`.
.. rubric:: |prereq|
For |AIO-SX| deployment configurations, the end user container images in
`registry.local` will be backed up during the upgrade process. This only
includes images other than |prod| system and application images. These images
are limited to 5 GB in total size. If the system contains more than 5 GB of
these images, the upgrade start will fail. For information on back up and restore,
see :ref:`backing-up-starlingx-system-data`.
The following prerequisites apply to a |prod-dc| upgrade management service.
.. _upgrade-management-overview-ul-smx-y2m-cmb:
- Validate the list of new images with the target release. If you are using a
private registry for installs/upgrades, you must populate your private
registry with the new images prior to bootstrap and/or patch application.
- **Configuration Verification**: Ensure that the following configurations
are verified before you proceed with the upgrade on the |prod-dc|
and subclouds:
- Run the :command:`system application-list` command to ensure that all
applications are running.
- Run the :command:`system host-list` command to list the configured
hosts.
- Run the :command:`dcmanager subcloud list` command to list the
subclouds.
- Run the :command:`kubectl get pods --all-namespaces` command to test
that the authentication token validates correctly.
- Run the :command:`fm alarm-list` command to ensure that there are no
unexpected or management-affecting alarms.
- Run the :command:`system health-query-upgrade` command to check the
system health to ensure that the system meets all the upgrade prerequisites.
- Run the :command:`kubectl get host -n deployment` command to ensure all
nodes in the cluster have reconciled and is set to 'true'.
- Ensure **controller-0** is the active controller.
- The |AIO-SX| subclouds must use the Redfish platform management service.
- Ensure any certificates managed by cert manager will not be renewed during
the upgrade process.
.. only:: partner
.. include:: /_includes/upgrade-management-overview.rest

536
doc/source/dist_cloud/kubernetes/upgrading-the-systemcontroller-using-the-cli.rst
View File

@ -1,536 +0,0 @@
.. vco1593176327490
.. _upgrading-the-systemcontroller-using-the-cli:
===========================================
Upgrade the System Controller Using the CLI
===========================================
You can upload and apply a software upgrade (deploy a major release or patched
major Release) to the system controller, using the CLI. The software upgrade
not only upgrades software of the system controller but also updates software
in the system controller's |prod-dc| vault and the central container image
repository, in support of subsequent subcloud upgrades.
The system controller can be upgraded using either a :ref:`manual software
upgrade <manual-host-software-deployment-ee17ec6f71a4>` or by using the
standalone cloud :ref:`orchestrated software upgraded procedure
<orchestrated-deployment-host-software-deployment-d234754c7d20>` with
:command:`sw-manager`.
.. rubric:: |context|
Follow the steps below to manually upgrade the system controller:
.. rubric:: |prereq|
.. only:: starlingx
- Transfer the ISO and signature files for the new major release (or new
patched major release) from the |prod-long| mirror
https://mirror.starlingx.cengn.ca/mirror/starlingx/release/latest_release/debian/monolithic/outputs/iso/
to controller-0 (active controller).
- Upgrade to a patched major release (patched ISO).
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: manualupgrade1-begin
:end-before: manualupgrade1-end
.. only:: starlingx
- If you are using a private registry (see the ``docker / *-registry``
sections of `system service-parameter-list`), transfer the container
image versions associated with the new major release (or new patched
major release) using the list from |prod-long| mirror
https://mirror.starlingx.cengn.ca/mirror/starlingx/release/latest_release/debian/monolithic/outputs/docker-images/
from docker.io to the private registry.
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: manualupgrade2-begin
:end-before: manualupgrade2-end
- The platform issuer (system-local-ca) is required to have an RSA
certificate/private key pair before upgrading. If ``system-local-ca`` was
configured with a different type of certificate/private key, the deploy pre
check will fail with an informative message. In this case, the
:ref:`migrate-platform-certificates-to-use-cert-manager-c0b1727e4e5d`
procedure needs to be executed to reconfigure ``system-local-ca`` with the
RSA certificate/private key targeting the ``SystemController`` and all
subclouds.
- If there are software updates for your current |prod| software release that
are required in order to upgrade to the new software release, these
patches/updates should be applied in a separate software deploy of the
patch release(s) (see :ref:`manual-host-software-deployment-ee17ec6f71a4`)
on the system controller. These patches/updates should also be applied in
an orchestrated software deploy of the subclouds (see
:ref:`orchestrated-deployment-host-software-deployment-d234754c7d20`) in
order to get patch current of all the systems before starting the upgrade
to the new major release on the |prod-dc| system.
.. rubric:: |proc|
.. _upgrading-the-systemcontroller-using-the-cli-steps-oq4-dgm-cmb:
#. Source the platform environment.
.. code-block:: none
$ source /etc/platform/openrc
~(keystone_admin)]$
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: license-begin
:end-before: license-end
#. Upload the load.
.. only:: starlingx
.. parsed-literal::
~(keystone_admin)]$ software upload --local /full_path/<bootimage>.iso /full_path/<bootimage>.sig
+-------------------------------+--------------------------+
| Uploaded File | Release |
+-------------------------------+--------------------------+
| starlingx-intel-x86-64-cd.iso | stx-10.0.0 |
+-------------------------------+--------------------------+
.. only:: partner
.. include:: /_includes/software-upload-output.rest
:start-after: software-upload-begin
:end-before: software-upload-end
.. note::
Do not use ``--os-region-name SystemController`` proxy at this moment for
subcloud deployment. This step will be performed once the system
controller deploy is complete.
.. note::
If you face any issue while importing the load, go to
``/var/log/software.log`` and examine the error messages.
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: wrsbegin
:end-before: wrsend
#. Confirm that the system is healthy.
Check the current system health status, resolve any alarms and other issues
reported by the :command:`software deploy precheck <release-id>` command
then recheck the system health status to confirm that all **System Health**
fields are set to **OK**.
.. code-block:: none
~(keystone_admin)]$ software deploy precheck <release-id>
System Health:
All hosts are provisioned: [OK]
All hosts are unlocked/enabled: [OK]
All hosts have current configurations: [OK]
Ceph Storage Healthy: [OK]
No alarms: [OK]
All kubernetes nodes are ready: [OK]
All kubernetes control plane pods are ready: [OK]
All kubernetes applications are in a valid state: [OK]
All hosts are patch current: [OK]
Active kubernetes version [vX.XX.X] is a valid supported version: [OK]
Active controller is controller-0: [OK]
Installed license is valid: [OK]
Valid upgrade path from release 22.12 to 24.09: [OK]
Required patches are applied: [OK]
.. only:: starlingx
Where ``<release-id>`` is stx-10.0.0 for above software upload
example, or it can be found out by running :command:`software list`.
.. only:: partner
.. include:: /_includes/software-upload-output.rest
:start-after: software-upload-precheck-begin
:end-before: software-upload-precheck-end
By default, the deploy process cannot run and is not recommended to run
with active alarms present. It is strongly recommended that you clear your
system of all alarms before doing a deploy.
#. Begin the deploy from controller-0.
Make sure that controller-0 is the active controller, and you are logged
into controller-0 as **sysadmin** and your present working directory is
your home directory.
.. code-block:: none
~(keystone_admin)]$ software deploy start <release-id>
+--------------+------------+------+--------------+
| From Release | To Release | RR | State |
+--------------+------------+------+--------------+
| 22.12.0 | 24.09.100 | True | deploy-start |
+--------------+------------+------+--------------+
.. note::
It is recommended to run the :command:`software deploy precheck`
command before running :command:`software deploy start`. However, the
:command:`software deploy start` command will automatically run
the precheck command even if the precheck command has not been run
before.
Wait for :command:`software deploy start <release-id>` to complete by monitoring the
status of the deploy.
.. code-block:: none
~(keystone_admin)]$ software deploy show
+--------------+------------+------+-------------------+
| From Release | To Release | RR | State |
+--------------+------------+------+-------------------+
| 22.12.0 | 24.09.100 | True | deploy-start-done |
+--------------+------------+------+-------------------+
:command:`software deploy start <release-id>` will migrate configuration
data to the new release's data model. Configuration must not be changed
after this point, until the deploy is completed.
#. Software deploy controller-1.
#. Lock controller-1.
.. code-block:: none
~(keystone_admin)]$ system host-lock controller-1
#. Begin the deploy on controller-1.
.. code-block:: none
~(keystone_admin)]$ software deploy host controller-1
Running major release deployment, major_release=24.09, force=False, async_req=False, commit_id=<commit-id>
Host installation was successful on controller-1
#. Unlock controller-1.
.. code-block:: none
~(keystone_admin)]$ system host-unlock controller-1
Wait for controller-1 to enter the ``unlocked-enabled`` state. Wait until
the DRBD sync **400.001** Services-related alarm has been raised and then
cleared.
When the first :command:`software deploy host <hostname>` command is
issued after the deploy state becomes ``deploy-start-done``, the
software deploy show state is changed to ``deploy-host``. When the
software is deployed to all the hosts, that is, when the
:command:`software deploy host <hostname>` successfully completes
against the last host, the software deploy show state changes to
``deploy-host-done``.
If software deploy show state transitions to
**unlocked-disabled-failed**, check the issue before proceeding to the
next step. The alarms may indicate a configuration error. Check the
result of the configuration logs on controller-1, (for example, Error
logs in controller-1:``/var/log/puppet``).
#. Run the :command:`system application-list` and :command:`software deploy host-list`
commands to view the current progress.
After controller-1 is unlocked/enabled/available, run the following step to check
controller-1 is running the new release:
.. code-block:: none
~(keystone_admin)]$ system host-show controller-1
#. Set controller-1 as the active controller. Swact away from controller-0.
.. code-block:: none
~(keystone_admin)]$ system host-swact controller-0
Wait until services have gone active on the new active controller-1 before
proceeding to the next step. When all services on controller-1 are
enabled-active, the swact is complete.
#. Software deploy controller-0.
For more information, see
:ref:`introduction-platform-software-updates-upgrades-06d6de90bbd0`.
#. Lock controller-0.
.. code-block:: none
~(keystone_admin)]$ system host-lock controller-0
#. Begin the deploy on controller-0.
.. code-block:: none
~(keystone_admin)]$ software deploy host controller-0
Running major release deployment, major_release=24.09, force=False, async_req=False, commit_id=<commit-id>
#. Unlock controller-0.
.. code-block:: none
~(keystone_admin)]$ system host-unlock controller-0
#. Check the system health to ensure that there are no unexpected alarms.
.. code-block:: none
~(keystone_admin)]$ fm alarm-list
Clear all alarms unrelated to the deploy process.
#. If using Ceph storage backend, deploy the storage nodes one at a time.
The storage node must be locked and all |OSDs| must be down in order to do
the upgrade.
#. Lock storage-0.
.. code-block:: none
~(keystone_admin)]$ system host-lock storage-0
#. Verify that the |OSDs| are down after the storage node is locked.
.. code-block:: none
~(keystone_admin)]$ ceph osd tree
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| ID | CLASS | WEIGHT | TYPE | NAME | STATUS | REWEIGHT | PRI-AFF |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| -1 | | 0.01700 | root | storage-tier | | | |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| -2 | | 0.01700 | chassis | group-0 | | | |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| -4 | | 0.00850 | host | controller-0 | | | |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| 0 | hdd | 0.00850 | | osd.0 | up | 1.00000 | 1.00000 |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| -3 | | 0.00850 | host | controller-1 | | | |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
| 1 | hdd | 0.00850 | | osd.1 | down | 1.00000 | 1.00000 |
+----+---------+------------+---------+-------------------+-------------+------------------+-------------+
#. Begin the deploy on storage-0.
.. code-block:: none
~(keystone_admin)]$ software deploy host storage-0
The deploy is complete when the node comes online, and at that point,
you can safely unlock the node.
After upgrading a storage node, but before unlocking, there are Ceph
synchronization alarms (that appear to be making progress in
synching), and there are infrastructure network interface alarms
(since the infrastructure network interface configuration has not been
applied to the storage node yet, as it has not been unlocked).
Unlock the node as soon as the deployed storage node comes online.
#. Unlock storage-0.
.. code-block:: none
~(keystone_admin)]$ system host-unlock storage-0
Wait for all alarms to clear after the unlock before proceeding to
deploy the next storage host.
#. Repeat the above steps for each storage host.
.. note::
After deploying the first storage node you can expect alarm
**800.003**. The alarm is cleared after all storage nodes are
deployed.
#. If worker nodes are present, deploy worker hosts, serially or in parallel,
if any.
#. Lock worker-0.
.. code-block:: none
~(keystone_admin)]$ system host-lock worker-0
#. Deploy worker-0.
.. code-block:: none
~(keystone_admin)]$ software deploy host worker-0
Wait for the host to run the installer, reboot, and go online before
unlocking it in the next step.
#. Unlock worker-0.
.. code-block:: none
~(keystone_admin)]$ system host-unlock worker-0
Wait for all alarms to clear after the unlock before proceeding to the
next worker host.
#. Repeat the above steps for each worker host.
#. Set controller-0 as the active controller. Swact away from controller-1.
.. code-block:: none
~(keystone_admin)]$ system host-swact controller-1
Wait until services have gone active on the active controller-0 before
proceeding to the next step. When all services on controller-0 are
enabled-active, the swact is complete.
#. Activate the deploy.
.. code-block:: none
~(keystone_admin)]$ software deploy activate
Deploy activate has started
Check deploy state:
.. code-block:: none
~(keystone_admin)]$ software deploy show
+--------------+------------+------+-----------------+
| From Release | To Release | RR | State |
+--------------+------------+------+-----------------+
| 22.12.0 | 24.09.100 | True | deploy-activate |
+--------------+------------+------+-----------------+
Wait for :command:`software deploy activate` to complete by monitoring the
status of the deploy.
.. code-block:: none
~(keystone_admin)]$ software deploy show
+--------------+------------+------+----------------------+
| From Release | To Release | RR | State |
+--------------+------------+------+----------------------+
| 22.12.0 | 24.09.100 | True | deploy-activate-done |
+--------------+------------+------+----------------------+
During the running of the :command:`software deploy activate` command, new
configurations are applied to the controller. 250.001 (**hostname
Configuration is out-of-date**) alarms are raised and are cleared as the
configuration is applied. The deploy state goes from ``deploy-activate`` to
``deploy-activate-done`` once this is done.
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: deploymentmanager-begin
:end-before: deploymentmanager-end
The following states apply when this command is executed.
**deploy-activate**
State entered when deploy is being activated.
**deploy-activate-done**
State entered when the deploy-activate completes successfully.
.. note::
This can take more than 15 minutes to complete.
.. note::
Alarms are generated as the subcloud software sync_status is "out-of-sync".
#. Complete the upgrade.
.. code-block:: none
~(keystone_admin)]$ software deploy complete
Deployment has been completed
Verify deploy state:
.. code-block:: none
~(keystone_admin)]$ software deploy show
+--------------+------------+------+-----------------------+
| From Release | To Release | RR | State |
+--------------+------------+------+-----------------------+
| 22.12.0 | 24.09.100 | True | deploy-completed |
+--------------+------------+------+-----------------------+
#. Upgrade Kubernetes, after the platform deploy is completed. To upgrade
Kubernetes of standalone system, see :ref:`index-updates-kub-03d4d10fa0be`.
#. When the Kubernetes upgrade completes, conclude the platform deploy by deleting
it.
.. code-block:: none
~(keystone_admin)]$ software deploy delete
Deploy deleted with success
Verify deploy state:
.. code-block:: none
~(keystone_admin)]$ software deploy show
No deploy in progress
#. Upload the load for subcloud deployment.
.. only:: starlingx
.. parsed-literal::
~(keystone_admin)]$ software --os-region-name SystemController upload --local /full_path/<bootimage>.iso /full_path/<bootimage>.sig
+-------------------------------+--------------------------+
| Uploaded File | Release |
+-------------------------------+--------------------------+
| starlingx-intel-x86-64-cd.iso | stx-10.0.0 |
+-------------------------------+--------------------------+
.. only:: partner
.. include:: /_includes/software-upload-output.rest
:start-after: software-load-begin
:end-before: software-load-end
.. note::
This can take a few minutes. After the system controller is successfully
deployed, the old load (which is in imported state) should not be deleted
from load list as this load is required for managing the subclouds that
are still running the previous load.
.. only:: partner
.. include:: /_includes/upgrading-the-systemcontroller-using-the-cli.rest
:start-after: DMupgrades-begin
:end-before: DMupgrades-end
.. rubric:: |postreq|
Separately apply the patches after the upgrade to the major release.

68
doc/source/dist_cloud/kubernetes/upload-software-releases-using-the-cli-203af02d6457.rst Normal file
View File

@ -0,0 +1,68 @@
.. WARNING: Add no lines of text between the label immediately following
.. and the title.
.. _upload-software-releases-using-the-cli-203af02d6457:
======================================
Upload Software Releases Using the CLI
======================================
New major or patch software releases must be uploaded to central software
release repository before they can be deployed on the System Controller and all
applicable subclouds.
Upload one or more patch releases
---------------------------------
#. Log in the System Controller as sysadmin user.
#. Transfer all patch releases to be uploaded to a directory e.g.
``/home/sysadmin/patches``.
#. Upload all patches in the directory to the central software release
repository.
.. code-block:: none
~(keystone_admin)]$ software --os-region-name SystemController upload-dir /home/sysadmin/patches
To upload a single patch release use the following command:
.. code-block:: none
~(keystone_admin)]$ software --os-region-name SystemController upload <patch-file-name>
Upload a major release
----------------------
#. Log in the System Controller as sysadmin user.
#. Transfer the iso and signature files to ``/home/sysadmin``.
#. Upload the boot image iso and signature files to the central software
release repository.
.. code-block:: none
~(keystone_admin)]$ software upload --local <bootimage.iso> <bootimage.sig>
.. note::
When using the --local option, you must provide the absolute path to the
release files.
View the uploaded release(s)
----------------------------
.. code-block:: none
~(keystone_admin)]$ software --os-region-name SystemController list
.. note::
You can also view the list of software releases locally to the Central
Cloud using the ``software list`` or ``software --os-region-name RegionOne
list`` command. The output should be the same as ``software -os-region-name
SystemController list`` command output.

43
doc/source/dist_cloud/kubernetes/upload-software-releases-using-the-horizon-dashboard-67b418278e55.rst Normal file
View File

@ -0,0 +1,43 @@
.. WARNING: Add no lines of text between the label immediately following
.. and the title.
.. _upload-software-releases-using-the-horizon-dashboard-67b418278e55:
====================================================
Upload Software Releases Using the Horizon Dashboard
====================================================
You can also upload software releases to the central software release
repository from the Horizon Web interface.
.. rubric:: |context|
If you prefer, you can use the |CLI|. For more information, see
:ref:`upload-software-releases-using-the-cli-203af02d6457`.
.. rubric:: |proc|
#. Select the **SystemController** region.
.. image:: figures/system-controller-region.png
#. Select **Distributed Cloud Admin** \> **Software Management**.
#. On the **Software Management** page, select the **Releases** tab.
.. image:: figures/software-management-system-controller.png
:width: 1000px
#. On the **Releases** tab, click **Upload Releases**.
In the **Upload Releases** dialog box, click **Choose Files** to select
the software release files for upload.
.. image:: figures/upload-releases-pop.png
#. In the dialog, click **Upload Releases**.
The release is added to the Releases list in the **Available** state.
.. image:: figures/releases-list-state.png

84
doc/source/dist_cloud/kubernetes/uploading-and-applying-updates-to-systemcontroller-using-horizon.rst
View File

@ -1,84 +0,0 @@
.. iru1558615665841
.. _uploading-and-applying-updates-to-systemcontroller-using-horizon:
==========================================================
Upload and Apply Updates to SystemController Using Horizon
==========================================================
You can upload and apply updates (patches) to the SystemController in order
to update the central update repository, from the Horizon Web interface.
.. rubric:: |context|
If you prefer, you can use the |CLI|. For more information, see
:ref:`uploading-and-applying-updates-to-systemcontroller-using-the-cli`.
.. rubric:: |proc|
#. Select the **SystemController** region.
#. Select **Distributed Cloud Admin** \> **Software Management**.
#. On the **Software Management** page, select the **Releases** tab.
.. image:: figures/software-management-system-controller.png
:width: 1000px
#. On the **Releases** tab, click **Upload Releases**.
In the **Upload Releases** dialog box, click **Choose Files** to select
updates (releases) for upload.
#. In the dialog, click **Upload Releases**.
The update is added to the Releases list in the **Available** state.
.. image:: figures/uzw1525102534768.png
#. Click **Deploy Start**.
The state is updated to **Deploying**.
.. _uploading-and-applying-updates-to-systemcontroller-using-horizon-update-the-regionone:
--------------------
Update the RegionOne
--------------------
To fully deploy the Central Cloud's RegionOne through Horizon:
#. Upload and apply updates to SystemController region.
.. For more details see :ref:`configuring-update-orchestration`.
#. Update the RegionOne region:
#. Change to the RegionOne region (top left drop-down menu).
.. image:: figures/regionone.png
#. Go to **Admin** \> **Platform** \> **Software Management** and open the
**Deploy Orchestration** tab.
#. Select **Create Strategy**.
#. Create an update strategy by specifying settings for the parameters in
the **Create Strategy** dialog box.
#. Click **Apply Strategy** to apply the update strategy.
.. To update the RegionOne using the CLI see :ref:`update-orchestration-cli`.
.. This procedure closely resembles what is described in
:ref:`configuring-update-orchestration`. The key difference lies in the
necessity to preselect RegionOne.
.. rubric:: |postreq|
To update the software on the System Controller and subclouds, you must use the
|prod-dc| Update Orchestration. For more information, see
:ref:`update-orchestration-of-central-clouds-regionone-and-subclouds`.

112
doc/source/dist_cloud/kubernetes/uploading-and-applying-updates-to-systemcontroller-using-the-cli.rst
View File

@ -1,112 +0,0 @@
.. clv1558615616705
.. _uploading-and-applying-updates-to-systemcontroller-using-the-cli:
==========================================================
Upload and Apply Updates to SystemController Using the CLI
==========================================================
You can upload and apply updates to the SystemController in order to update the
central update repository, from the CLI using the standard update procedures
for |prod|. For |prod-dc|, you must include an additional |CLI| parameter.
.. rubric:: |context|
If you prefer, you can use the Horizon Web interface. For more information, see
:ref:`uploading-and-applying-updates-to-systemcontroller-using-horizon`,
however the specific procedure for incrementally uploading and applying one or
more patches for the SystemController is provided below.
For standard |prod| updating procedures, see the |updates-doc|:
:ref:`introduction-platform-software-updates-upgrades-06d6de90bbd0` guide.
For SystemController of |prod-dc| (and the central update repository), you
must include the additional |CLI| parameter ``--os-region-name`` with the value
SystemController when using |CLI| :command:`sw-patch` commands.
.. note::
When adding a new subcloud, you only need to create and apply an update
strategy to apply all updates that were previously applied in the system
controller to the new subcloud.
.. note::
The following existing :command:`sw-patch` commands are not supported in
the System Controller region:
.. _uploading-and-applying-updates-to-systemcontroller-using-the-cli-ul-fvw-cj4-3jb:
- :command:`sw-patch query-hosts`
- :command:`sw-patch host-install`
- :command:`sw-patch host-install-async`
- :command:`sw-patch host-install-local`
- :command:`sw-patch drop-host`
.. rubric:: |proc|
.. _uploading-and-applying-updates-to-systemcontroller-using-the-cli-steps-scm-jkx-fdb:
#. Log in as the **sysadmin** user.
#. Copy all patches to be uploaded and applied to ``/home/sysadmin/patches/``.
#. Upload all patches placed in ``/home/sysadmin/patches/`` to the storage area.
.. code-block:: none
~(keystone_admin)]$ sw-patch upload-dir /home/sysadmin/patches --os-region-name SystemController
.. note::
You may receive a warning about the update already being imported. This
is expected and occurs if the update was uploaded locally to the system
controller. The warning will only occur for patches that were applied
to controller-0 (system controller) before it was first unlocked.
#. Confirm that the newly uploaded patches have a status of **available**.
.. code-block:: none
~(keystone_admin)]$ sw-patch query --os-region-name SystemController
#. Apply all available updates in a single operation.
.. code-block:: none
~(keystone_admin)]$ sw-patch apply --all --os-region-name SystemController
#. Confirm that the updates have been applied.
.. code-block:: none
~(keystone_admin)]$ sw-patch query --os-region-name SystemController
#. To update the RegionOne, create the patch strategy using:
.. code-block:: none
~(keystone_admin)]$ sw-manager patch-strategy create
#. Apply the patch strategy:
.. code-block:: none
~(keystone_admin)]$ sw-manager patch-strategy apply
.. note::
The system controller is not included in the |DC| patch orchestration
strategy anymore. You need to patch the system controller before using
|DC| orchestration to patch the subclouds.
.. rubric:: |postreq|
To update the software on the subclouds, you must use the |prod-dc| Update
Orchestration. For more information, see
:ref:`update-orchestration-of-central-clouds-regionone-and-subclouds`.

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

@ -39,7 +39,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-software-deploy-orchestration-process-using-the-cli`.
:ref:`deploy-software-releases-using-the-cli-1ea02eb230e5`.
Software deployment orchestration automatically iterates through all the hosts
and deploys the new software load on each host: first the controller hosts,