starlingx/docs
Code Issues Proposed changes

Merge "Node Management and Distributed cloud Guide updates Global Pass Upgrades" into r/stx.5.0

Browse Source
This commit is contained in:
Zuul
2021-06-23 20:42:49 +00:00
committed by Gerrit Code Review
parent d7bb0f1c59 5c8f7b1d22
commit 18e996e173
41 changed files with 235 additions and 319 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/cli_ref/system.rst
View File

@@ -937,7 +937,7 @@ The following set of commands allow you to update the Intel N3000 |FPGA| |PAC|
user image on StarlingX hosts. user image on StarlingX hosts.
For more information, see For more information, see
:doc:`N3000 Overview </node_management/kubernetes/hardware_acceleration_devices/n3000-overview>`. :doc:`N3000 FPGA Overview </node_management/kubernetes/hardware_acceleration_devices/n3000-overview>`.
``host-device-image-update`` ``host-device-image-update``

24
doc/source/deploy_install_guides/r3_release/distributed_cloud/index.rst
View File

@@ -46,7 +46,7 @@ Distributed cloud architecture
------------------------------ ------------------------------
A distributed cloud system consists of a central cloud, and one or more A distributed cloud system consists of a central cloud, and one or more
subclouds connected to the SystemController region central cloud over L3 subclouds connected to the System Controller region central cloud over L3
networks, as shown in Figure 1. networks, as shown in Figure 1.
- **Central cloud** - **Central cloud**
@@ -65,13 +65,13 @@ networks, as shown in Figure 1.
In the Horizon GUI, SystemController is the name of the access mode, or In the Horizon GUI, SystemController is the name of the access mode, or
region, used to manage the subclouds. region, used to manage the subclouds.
You can use the SystemController to add subclouds, synchronize select You can use the System Controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations configuration data across all subclouds and monitor subcloud operations
and alarms. System software updates for the subclouds are also centrally and alarms. System software updates for the subclouds are also centrally
managed and applied from the SystemController. managed and applied from the System Controller.
DNS, NTP, and other select configuration settings are centrally managed DNS, NTP, and other select configuration settings are centrally managed
at the SystemController and pushed to the subclouds in parallel to at the System Controller and pushed to the subclouds in parallel to
maintain synchronization across the distributed cloud. maintain synchronization across the distributed cloud.
- **Subclouds** - **Subclouds**
@@ -81,7 +81,7 @@ networks, as shown in Figure 1.
(including simplex, duplex, or standard with or without storage nodes), can (including simplex, duplex, or standard with or without storage nodes), can
be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds. be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds.
Alarms raised at the subclouds are sent to the SystemController for Alarms raised at the subclouds are sent to the System Controller for
central reporting. central reporting.
.. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png .. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png
@@ -95,21 +95,21 @@ networks, as shown in Figure 1.
Network requirements Network requirements
-------------------- --------------------
Subclouds are connected to the SystemController through both the OAM and the Subclouds are connected to the System Controller through both the OAM and the
Management interfaces. Because each subcloud is on a separate L3 subnet, the Management interfaces. Because each subcloud is on a separate L3 subnet, the
OAM, Management and PXE boot L2 networks are local to the subclouds. They are OAM, Management and PXE boot L2 networks are local to the subclouds. They are
not connected via L2 to the central cloud, they are only connected via L3 not connected via L2 to the central cloud, they are only connected via L3
routing. The settings required to connect a subcloud to the SystemController routing. The settings required to connect a subcloud to the System Controller
are specified when a subcloud is defined. A gateway router is required to are specified when a subcloud is defined. A gateway router is required to
complete the L3 connections, which will provide IP routing between the complete the L3 connections, which will provide IP routing between the
subcloud Management and OAM IP subnet and the SystemController Management and subcloud Management and OAM IP subnet and the System Controller Management and
OAM IP subnet, respectively. The SystemController bootstraps the subclouds via OAM IP subnet, respectively. The System Controller bootstraps the subclouds via
the OAM network, and manages them via the management network. For more the OAM network, and manages them via the management network. For more
information, see the `Install a Subcloud`_ section later in this guide. information, see the `Install a Subcloud`_ section later in this guide.
.. note:: .. note::
All messaging between SystemControllers and Subclouds uses the ``admin`` All messaging between System Controllers and Subclouds uses the ``admin``
REST API service endpoints which, in this distributed cloud environment, REST API service endpoints which, in this distributed cloud environment,
are all configured for secure HTTPS. Certificates for these HTTPS are all configured for secure HTTPS. Certificates for these HTTPS
connections are managed internally by StarlingX. connections are managed internally by StarlingX.
@@ -159,12 +159,12 @@ At the subcloud location:
2. Physically install the top of rack switch and configure it for the 2. Physically install the top of rack switch and configure it for the
required networks. required networks.
3. Physically install the gateway routers which will provide IP routing 3. Physically install the gateway routers which will provide IP routing
between the subcloud OAM and Management subnets and the SystemController between the subcloud OAM and Management subnets and the System Controller
OAM and management subnets. OAM and management subnets.
4. On the server designated for controller-0, install the StarlingX 4. On the server designated for controller-0, install the StarlingX
Kubernetes software from USB or a PXE Boot server. Kubernetes software from USB or a PXE Boot server.
5. Establish an L3 connection to the SystemController by enabling the OAM 5. Establish an L3 connection to the System Controller by enabling the OAM
interface (with OAM IP/subnet) on the subcloud controller using the interface (with OAM IP/subnet) on the subcloud controller using the
``config_management`` script. This step is for subcloud ansible bootstrap ``config_management`` script. This step is for subcloud ansible bootstrap
preparation. preparation.

22
doc/source/deploy_install_guides/r4_release/distributed_cloud/index.rst
View File

@@ -65,13 +65,13 @@ networks, as shown in Figure 1.
In the Horizon GUI, SystemController is the name of the access mode, or In the Horizon GUI, SystemController is the name of the access mode, or
region, used to manage the subclouds. region, used to manage the subclouds.
You can use the SystemController to add subclouds, synchronize select You can use the System Controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations configuration data across all subclouds and monitor subcloud operations
and alarms. System software updates for the subclouds are also centrally and alarms. System software updates for the subclouds are also centrally
managed and applied from the SystemController. managed and applied from the System Controller.
DNS, NTP, and other select configuration settings are centrally managed DNS, NTP, and other select configuration settings are centrally managed
at the SystemController and pushed to the subclouds in parallel to at the System Controller and pushed to the subclouds in parallel to
maintain synchronization across the distributed cloud. maintain synchronization across the distributed cloud.
- **Subclouds** - **Subclouds**
@@ -81,7 +81,7 @@ networks, as shown in Figure 1.
(including simplex, duplex, or standard with or without storage nodes), can (including simplex, duplex, or standard with or without storage nodes), can
be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds. be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds.
Alarms raised at the subclouds are sent to the SystemController for Alarms raised at the subclouds are sent to the System Controller for
central reporting. central reporting.
.. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png .. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png
@@ -95,21 +95,21 @@ networks, as shown in Figure 1.
Network requirements Network requirements
-------------------- --------------------
Subclouds are connected to the SystemController through both the OAM and the Subclouds are connected to the System Controller through both the OAM and the
Management interfaces. Because each subcloud is on a separate L3 subnet, the Management interfaces. Because each subcloud is on a separate L3 subnet, the
OAM, Management and PXE boot L2 networks are local to the subclouds. They are OAM, Management and PXE boot L2 networks are local to the subclouds. They are
not connected via L2 to the central cloud, they are only connected via L3 not connected via L2 to the central cloud, they are only connected via L3
routing. The settings required to connect a subcloud to the SystemController routing. The settings required to connect a subcloud to the System Controller
are specified when a subcloud is defined. A gateway router is required to are specified when a subcloud is defined. A gateway router is required to
complete the L3 connections, which will provide IP routing between the complete the L3 connections, which will provide IP routing between the
subcloud Management and OAM IP subnet and the SystemController Management and subcloud Management and OAM IP subnet and the System Controller Management and
OAM IP subnet, respectively. The SystemController bootstraps the subclouds via OAM IP subnet, respectively. The System Controller bootstraps the subclouds via
the OAM network, and manages them via the management network. For more the OAM network, and manages them via the management network. For more
information, see the `Install a Subcloud`_ section later in this guide. information, see the `Install a Subcloud`_ section later in this guide.
.. note:: .. note::
All messaging between SystemControllers and Subclouds uses the ``admin`` All messaging between System Controllers and Subclouds uses the ``admin``
REST API service endpoints which, in this distributed cloud environment, REST API service endpoints which, in this distributed cloud environment,
are all configured for secure HTTPS. Certificates for these HTTPS are all configured for secure HTTPS. Certificates for these HTTPS
connections are managed internally by StarlingX. connections are managed internally by StarlingX.
@@ -159,12 +159,12 @@ At the subcloud location:
2. Physically install the top of rack switch and configure it for the 2. Physically install the top of rack switch and configure it for the
required networks. required networks.
3. Physically install the gateway routers which will provide IP routing 3. Physically install the gateway routers which will provide IP routing
between the subcloud OAM and Management subnets and the SystemController between the subcloud OAM and Management subnets and the System Controller
OAM and management subnets. OAM and management subnets.
4. On the server designated for controller-0, install the StarlingX 4. On the server designated for controller-0, install the StarlingX
Kubernetes software from USB or a PXE Boot server. Kubernetes software from USB or a PXE Boot server.
5. Establish an L3 connection to the SystemController by enabling the OAM 5. Establish an L3 connection to the System Controller by enabling the OAM
interface (with OAM IP/subnet) on the subcloud controller using the interface (with OAM IP/subnet) on the subcloud controller using the
``config_management`` script. This step is for subcloud ansible bootstrap ``config_management`` script. This step is for subcloud ansible bootstrap
preparation. preparation.

22
doc/source/deploy_install_guides/r5_release/distributed_cloud/index.rst
View File

@@ -65,13 +65,13 @@ networks, as shown in Figure 1.
In the Horizon GUI, SystemController is the name of the access mode, or In the Horizon GUI, SystemController is the name of the access mode, or
region, used to manage the subclouds. region, used to manage the subclouds.
You can use the SystemController to add subclouds, synchronize select You can use the System Controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations configuration data across all subclouds and monitor subcloud operations
and alarms. System software updates for the subclouds are also centrally and alarms. System software updates for the subclouds are also centrally
managed and applied from the SystemController. managed and applied from the System Controller.
DNS, NTP, and other select configuration settings are centrally managed DNS, NTP, and other select configuration settings are centrally managed
at the SystemController and pushed to the subclouds in parallel to at the System Controller and pushed to the subclouds in parallel to
maintain synchronization across the distributed cloud. maintain synchronization across the distributed cloud.
- **Subclouds** - **Subclouds**
@@ -81,7 +81,7 @@ networks, as shown in Figure 1.
(including simplex, duplex, or standard with or without storage nodes), can (including simplex, duplex, or standard with or without storage nodes), can
be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds. be used for a subcloud. The two edge clouds shown in Figure 1 are subclouds.
Alarms raised at the subclouds are sent to the SystemController for Alarms raised at the subclouds are sent to the System Controller for
central reporting. central reporting.
.. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png .. figure:: ../figures/starlingx-deployment-options-distributed-cloud.png
@@ -95,21 +95,21 @@ networks, as shown in Figure 1.
Network requirements Network requirements
-------------------- --------------------
Subclouds are connected to the SystemController through both the OAM and the Subclouds are connected to the System Controller through both the OAM and the
Management interfaces. Because each subcloud is on a separate L3 subnet, the Management interfaces. Because each subcloud is on a separate L3 subnet, the
OAM, Management and PXE boot L2 networks are local to the subclouds. They are OAM, Management and PXE boot L2 networks are local to the subclouds. They are
not connected via L2 to the central cloud, they are only connected via L3 not connected via L2 to the central cloud, they are only connected via L3
routing. The settings required to connect a subcloud to the SystemController routing. The settings required to connect a subcloud to the System Controller
are specified when a subcloud is defined. A gateway router is required to are specified when a subcloud is defined. A gateway router is required to
complete the L3 connections, which will provide IP routing between the complete the L3 connections, which will provide IP routing between the
subcloud Management and OAM IP subnet and the SystemController Management and subcloud Management and OAM IP subnet and the System Controller Management and
OAM IP subnet, respectively. The SystemController bootstraps the subclouds via OAM IP subnet, respectively. The System Controller bootstraps the subclouds via
the OAM network, and manages them via the management network. For more the OAM network, and manages them via the management network. For more
information, see the `Install a Subcloud`_ section later in this guide. information, see the `Install a Subcloud`_ section later in this guide.
.. note:: .. note::
All messaging between SystemControllers and Subclouds uses the ``admin`` All messaging between System Controllers and Subclouds uses the ``admin``
REST API service endpoints which, in this distributed cloud environment, REST API service endpoints which, in this distributed cloud environment,
are all configured for secure HTTPS. Certificates for these HTTPS are all configured for secure HTTPS. Certificates for these HTTPS
connections are managed internally by StarlingX. connections are managed internally by StarlingX.
@@ -159,12 +159,12 @@ At the subcloud location:
2. Physically install the top of rack switch and configure it for the 2. Physically install the top of rack switch and configure it for the
required networks. required networks.
3. Physically install the gateway routers which will provide IP routing 3. Physically install the gateway routers which will provide IP routing
between the subcloud OAM and Management subnets and the SystemController between the subcloud OAM and Management subnets and the System Controller
OAM and management subnets. OAM and management subnets.
4. On the server designated for controller-0, install the StarlingX 4. On the server designated for controller-0, install the StarlingX
Kubernetes software from USB or a PXE Boot server. Kubernetes software from USB or a PXE Boot server.
5. Establish an L3 connection to the SystemController by enabling the OAM 5. Establish an L3 connection to the System Controller by enabling the OAM
interface (with OAM IP/subnet) on the subcloud controller using the interface (with OAM IP/subnet) on the subcloud controller using the
``config_management`` script. This step is for subcloud ansible bootstrap ``config_management`` script. This step is for subcloud ansible bootstrap
preparation. preparation.

18
doc/source/dist_cloud/certificate-management-for-admin-rest-api-endpoints.rst
View File

@@ -6,7 +6,7 @@
Certificate Management for Admin REST API Endpoints Certificate Management for Admin REST API Endpoints
=================================================== ===================================================
All messaging between SystemControllers and Subclouds in the |prod-dc| All messaging between System Controllers and Subclouds in the |prod-dc|
system uses the admin REST API service endpoints, which are all configured for system uses the admin REST API service endpoints, which are all configured for
secure HTTPS. secure HTTPS.
@@ -19,9 +19,9 @@ endpoints.
.. certificate-management-for-admin-rest--api-endpoints-section-lkn-ypk-xnb: .. certificate-management-for-admin-rest--api-endpoints-section-lkn-ypk-xnb:
------------------------------------ -------------------------------------
Certificates on the SystemController Certificates on the System Controller
------------------------------------ -------------------------------------
In a |prod-dc| system, the HTTPS certificates for admin endpoints are In a |prod-dc| system, the HTTPS certificates for admin endpoints are
managed by |prod| internally. managed by |prod| internally.
@@ -29,7 +29,7 @@ managed by |prod| internally.
.. note:: .. note::
All renewal operations are automatic, and no user operation is required. All renewal operations are automatic, and no user operation is required.
For admin endpoints, the SystemControllers in a |prod-dc| system For admin endpoints, the System Controllers in a |prod-dc| system
manages the following certificates: manages the following certificates:
@@ -39,7 +39,7 @@ manages the following certificates:
\(approximately 5 years\). Renewal of this certificate starts 30 days prior \(approximately 5 years\). Renewal of this certificate starts 30 days prior
to expiry. to expiry.
The Root |CA| certificate is renewed on the SystemController. When the The Root |CA| certificate is renewed on the System Controller. When the
certificate is renewed, |prod| renews the intermediate |CA| certificate is renewed, |prod| renews the intermediate |CA|
certificates for all subclouds. certificates for all subclouds.
@@ -66,7 +66,7 @@ certificates:
.. certificate-management-for-admin-rest--api-endpoints-ul-x51-3qk-xnb: .. certificate-management-for-admin-rest--api-endpoints-ul-x51-3qk-xnb:
- **DC-AdminEp-Intermediate-CA certificate**: The intermediate CA certificate - **DC-AdminEp-Intermediate-CA certificate**: The intermediate CA certificate
for a subcloud is renewed on the SystemController. It is sent to the for a subcloud is renewed on the System Controller. It is sent to the
subcloud using a Rest API. Therefore, a subcloud needs to be online to subcloud using a Rest API. Therefore, a subcloud needs to be online to
receive the renewed certificate. receive the renewed certificate.
@@ -84,9 +84,9 @@ certificates:
generated. The new |TLS| certificate is used to provide |TLS| termination. generated. The new |TLS| certificate is used to provide |TLS| termination.
The SystemController audits subcloud AdminEp certificates daily. It also audits The System Controller audits subcloud AdminEp certificates daily. It also audits
subcloud admin endpoints when a subcloud becomes online or managed. If the subcloud admin endpoints when a subcloud becomes online or managed. If the
subcloud admin endpoint is "out-of-sync", the SystemController initiates subcloud admin endpoint is "out-of-sync", the System Controller initiates
intermediate |CA| certificate renewal, to force subcloud renewal of the admin intermediate |CA| certificate renewal, to force subcloud renewal of the admin
endpoint certificate. endpoint certificate.

2
doc/source/dist_cloud/changing-the-admin-password-on-distributed-cloud.rst
View File

@@ -22,7 +22,7 @@ Ensure that all subclouds are managed and online.
System Controller. System Controller.
- In the SystemController context, select **Identity** \> **Users**. - In the System Controller context, select **Identity** \> **Users**.
Select **Change Password** from the **Edit** menu for the Admin user. Select **Change Password** from the **Edit** menu for the Admin user.
- From the |CLI|: - From the |CLI|:

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

@@ -10,14 +10,14 @@ A |prod-dc| system consists of a Central Cloud and one or more subclouds
connected to the Central Cloud over L3 networks. connected to the Central Cloud over L3 networks.
The Central Cloud has two regions: RegionOne, used to manage the nodes in the The Central Cloud has two regions: RegionOne, used to manage the nodes in the
Central Cloud, and SystemController, used to manage the subclouds in the Central Cloud, and System Controller, used to manage the subclouds in the
|prod-dc| system. You can select RegionOne or SystemController regions from 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 setting the <OS\_REGION\_NAME> environment variable
if using the CLI. if using the CLI.
**Central Cloud** **Central Cloud**
The Central Cloud provides a RegionOne region for managing the physical The Central Cloud provides a RegionOne region for managing the physical
platform of the Central Cloud and the SystemController region for managing platform of the Central Cloud and the System Controller region for managing
and orchestrating over the subclouds. and orchestrating over the subclouds.
The Central Cloud does not support worker hosts. All worker functions are The Central Cloud does not support worker hosts. All worker functions are
@@ -29,7 +29,7 @@ if using the CLI.
**System Controller** **System Controller**
The System Controller access mode, or region, for managing subclouds is The System Controller access mode, or region, for managing subclouds is
SystemController. System Controller.
You can use the System Controller to add subclouds, synchronize select You can use the System Controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations and configuration data across all subclouds and monitor subcloud operations and
@@ -95,7 +95,7 @@ if using the CLI.
L3 connections. The routers must be configured independently according to L3 connections. The routers must be configured independently according to
OEM instructions. OEM instructions.
All messaging between SystemControllers and Subclouds uses the **admin** All messaging between System Controllers and Subclouds uses the **admin**
REST API service endpoints which, in this distributed cloud environment, REST API service endpoints which, in this distributed cloud environment,
are all configured for secure HTTPS. Certificates for these HTTPS are all configured for secure HTTPS. Certificates for these HTTPS
connections are managed internally by |prod|. connections are managed internally by |prod|.

24
doc/source/dist_cloud/distributed-cloud-ports-reference.rst
View File

@@ -37,27 +37,27 @@ function correctly.
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 6386 | sysinv-api | System Controller | Subclouds | | | tcp | 6386 | sysinv-api | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 6443 | K8s API server | Not used between SystemController and Subclouds | | | | tcp | 6443 | K8s API server | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 7778 | stx-ha | Not used between SystemController and Subclouds | | | | tcp | 7778 | stx-ha | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8443 | horizon https | Not used between SystemController and Subclouds | | | | tcp | 8443 | horizon https | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8080 | horizon http | Not used between SystemController and Subclouds | Not required if using https | | | tcp | 8080 | horizon http | Not used between System Controller and Subclouds | Not required if using https | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8119 | stx-distcloud | Not used between SystemController and Subclouds | dcmanager-api | | | tcp | 8119 | stx-distcloud | Not used between System Controller and Subclouds | dcmanager-api | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 15491 | stx-update | Not used between SystemController and Subclouds | only required for system controller | | | tcp | 15491 | stx-update | Not used between System Controller and Subclouds | only required for system controller | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 18003 | stx-fault | SystemController | Subclouds | | | tcp | 18003 | stx-fault | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| icmp | icmp | | | | | | icmp | icmp | | | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 9312 | barbican | Not used between SystemController and Subclouds | | | | tcp | 9312 | barbican | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 319 | PTP | Not used between SystemController and Subclouds | | | | udp | 319 | PTP | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 320 | PTP | Not used between SystemController and Subclouds | | | | udp | 320 | PTP | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp/udp | 636 | LDAPS | Subcloud | Windows AD server | | | tcp/udp | 636 | LDAPS | Subcloud | Windows AD server | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
@@ -67,7 +67,7 @@ function correctly.
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp/udp | 30556 | DEC OIDC Provider | Subcloud | | | | tcp/udp | 30556 | DEC OIDC Provider | Subcloud | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8220 | Dist. cloud | SystemController | Subclouds | dcdbsync-api | | tcp | 8220 | Dist. cloud | System Controller | Subclouds | dcdbsync-api |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 31001 | Elastic \(using NodePort\) | Subcloud | DC | | | tcp | 31001 | Elastic \(using NodePort\) | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
@@ -77,6 +77,6 @@ function correctly.
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 162 | snmp trap | Subcloud | DC | | | udp | 162 | snmp trap | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8443 | https | Not used between SystemController and Subclouds | | | | tcp | 8443 | https | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+

41
doc/source/dist_cloud/distributed-upgrade-orchestration-process-using-the-cli.rst
View File

@@ -7,9 +7,8 @@ Distributed Upgrade Orchestration Process Using the CLI
======================================================= =======================================================
Distributed upgrade orchestration can be initiated after the upgrade and Distributed upgrade orchestration can be initiated after the upgrade and
stability of the SystemController cloud. Upgrade orchestration automatically stability of the System Controller cloud. Distributed upgrade orchestration can
iterates through each of the subclouds, installing the new software load on be initiated after the system controller has been successfully upgraded.
each one.
.. rubric:: |context| .. rubric:: |context|
@@ -26,8 +25,8 @@ using parameters to specify:
- whether to upgrade hosts serially or in parallel - whether to upgrade hosts serially or in parallel
Based on these parameters, and the state of the subclouds, distributed upgrade Based on these parameters, and the state of the subclouds, the upgrade
orchestration creates a number of stages for the overall upgrade strategy. All orchestrator creates a number of stages for the overall upgrade strategy. All
the subclouds that are included in the same stage will be upgraded in parallel. the subclouds that are included in the same stage will be upgraded in parallel.
.. rubric:: |prereq| .. rubric:: |prereq|
@@ -45,7 +44,7 @@ following conditions:
- Redfish |BMC| is required for orchestrated subcloud upgrades. The install - Redfish |BMC| is required for orchestrated subcloud upgrades. The install
values, and :command:`bmc\_password` for each |AIO-SX| subcloud controller values, and :command:`bmc\_password` for each |AIO-SX| subcloud controller
must be provided using the following |CLI| command on the SystemController: must be provided using the following |CLI| command on the System Controller:
.. code-block:: none .. code-block:: none
@@ -56,14 +55,14 @@ following conditions:
:ref:`Installing a Subcloud Using Redfish Platform Management Service :ref:`Installing a Subcloud Using Redfish Platform Management Service
<installing-a-subcloud-using-redfish-platform-management-service>`. <installing-a-subcloud-using-redfish-platform-management-service>`.
- All subclouds are clear of alarms \(with the exception of the alarm upgrade - All subclouds are clear of management-affecting alarms \(with the exception of the alarm upgrade
in progress\). in progress\).
- All hosts of all subclouds must be unlocked, enabled, and available. - All hosts of all subclouds must be unlocked, enabled, and available.
- No distributed update orchestration strategy exists, to verify use the - No distributed upgrade orchestration strategy exists, to verify use the
command :command:`dcmanager upgrade-stratagy-show`. An upgrade cannot be command :command:`dcmanager upgrade-strategy-show`. An upgrade cannot be
orchestrated while update orchestration is in progress. orchestrated while upgrade orchestration is in progress.
- Verify the size and format of the platform-backup filesystem on each - Verify the size and format of the platform-backup filesystem on each
subcloud. From the shell on each subcloud, use the following command to view subcloud. From the shell on each subcloud, use the following command to view
@@ -90,7 +89,7 @@ following conditions:
#. Review the upgrade status for the subclouds. #. Review the upgrade status for the subclouds.
After the SystemController upgrade is completed, wait for 10 minutes for After the System Controller upgrade is completed, wait for 10 minutes for
the **load\_sync\_status** of all subclouds to be updated. the **load\_sync\_status** of all subclouds to be updated.
To identify which subclouds are upgrade-current \(in-sync\), use the To identify which subclouds are upgrade-current \(in-sync\), use the
@@ -313,22 +312,10 @@ following conditions:
.. _distributed-upgrade-orchestration-process-using-the-cli-ul-lx1-zcv-3mb: .. _distributed-upgrade-orchestration-process-using-the-cli-ul-lx1-zcv-3mb:
- Check and update docker registry credentials for **ALL** subclouds. For The secret payload should be, "username: sysinv password:<password>". If
each subcloud: the secret payload is, "username: admin password:<password>", see,
:ref:`Update Docker Registry Credentials on a Subcloud
.. code-block:: none <updating-docker-registry-credentials-on-a-subcloud>` for more information.
REGISTRY="docker-registry"
SECRET_UUID='system service-parameter-list | fgrep
$REGISTRY | fgrep auth-secret | awk '{print $10}''
SECRET_REF='openstack secret list | fgrep ${SECRET_UUID}|
awk '{print $2}''
openstack secret get ${SECRET_REF} --payload -f value
The secret payload should be, "username: sysinv password:<password>". If
the secret payload is, "username: admin password:<password>", see,
:ref:`Updating Docker Registry Credentials on a Subcloud
<updating-docker-registry-credentials-on-a-subcloud>` for more information.
.. only:: partner .. only:: partner

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

@@ -23,8 +23,6 @@ Errors can occur due to one of the following:
- A network error that results in the subcloud's being temporarily unreachable - A network error that results in the subcloud's being temporarily unreachable
- An invalid docker registry certificate
**Failure Caused by Install Values** **Failure Caused by Install Values**
@@ -35,8 +33,8 @@ command to fix it.
~(keystone_admin)]$ dcmanager subcloud update <<subcloud-name>> --install-values <<subcloud-install-values-yaml>> ~(keystone_admin)]$ dcmanager subcloud update <<subcloud-name>> --install-values <<subcloud-install-values-yaml>>
This type of failure is recoverable and you can rerun the upgrade strategy for This type of failure is recoverable and you can retry the orchestrated
the failed subcloud\(s\) using the following procedure: upgrade for each of the failed subclouds using the following procedure:
.. rubric:: |proc| .. rubric:: |proc|
@@ -74,50 +72,6 @@ the failed subcloud\(s\) using the following procedure:
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-section-f5f-j1y-qmb: .. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-section-f5f-j1y-qmb:
-----------------------------------------------------
Failure Caused by Invalid Docker Registry Certificate
-----------------------------------------------------
If the docker registry certificate on the subcloud is invalid/expired prior to
an upgrade, the upgrade will fail during data migration.
.. warning::
This type of failure cannot be recovered. You will need to re-deploy the
subcloud, redo all configuration changes, and regenerate the data.
.. note::
Ensure that the docker registry certificate on all subclouds must be
upgraded prior to performing an orchestrated upgrade.
To re-deploy the subcloud, use the following procedure:
.. rubric:: |proc|
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-ol-dpp-bzr-qmb:
#. Unmanage the failed subcloud.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud unmanage <<subcloud-name>>
#. Delete the subcloud.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud delete <<subcloud-name>>
#. Re-deploy the failed subcloud.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud add <<parameters>>
.. _failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud-section-lj4-1rr-qmb:
----------------------------------------- -----------------------------------------
Failure Post Data Migration on a Subcloud Failure Post Data Migration on a Subcloud
----------------------------------------- -----------------------------------------

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

@@ -26,8 +26,8 @@ Errors can occur due to any one of the following:
- The /home/sysadmin directory on the subcloud is too large - The /home/sysadmin directory on the subcloud is too large
If you encounter any of the above errors, use the following procedure to fix If you encounter any of the above errors, follow this procedure to retry the
it: orchestrated upgrade after addressing the cause of failure:
.. rubric:: |proc| .. rubric:: |proc|

12
doc/source/dist_cloud/index.rst
View File

@@ -49,6 +49,18 @@ Operation
changing-the-admin-password-on-distributed-cloud changing-the-admin-password-on-distributed-cloud
updating-docker-registry-credentials-on-a-subcloud updating-docker-registry-credentials-on-a-subcloud
----------------------
Manage Subcloud Groups
----------------------
.. toctree::
:maxdepth: 1
:caption: Contents:
managing-subcloud-groups
creating-subcloud-groups
ochestration-strategy-using-subcloud-groups
------------------------- -------------------------
Update (Patch) management Update (Patch) management
------------------------- -------------------------

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

@@ -30,20 +30,20 @@ subcloud, the subcloud installation has these phases:
.. note:: .. note::
After a successful remote installation of a subcloud in a Distributed Cloud After a successful remote installation of a subcloud in a Distributed Cloud
system, a subsequent remote reinstallation fails because of an existing ssh system, a subsequent remote reinstallation fails because of an existing ssh
key entry in the /root/.ssh/known\_hosts on the SystemController. In this key entry in the /root/.ssh/known\_hosts on the System Controller. In this
case, delete the host key entry, if present, from /root/.ssh/known\_hosts case, delete the host key entry, if present, from /root/.ssh/known\_hosts
on the SystemController before doing reinstallations. on the System Controller before doing reinstallations.
.. rubric:: |prereq| .. rubric:: |prereq|
.. _installing-a-subcloud-using-redfish-platform-management-service-ul-g5j-3f3-qjb: .. _installing-a-subcloud-using-redfish-platform-management-service-ul-g5j-3f3-qjb:
- The docker **rvmc** image needs to be added to the SystemController - The docker **rvmc** image needs to be added to the System Controller
bootstrap override file, docker.io/starlingx/rvmc:stx.5.0-v1.0.0. bootstrap override file, docker.io/starlingx/rvmc:stx.5.0-v1.0.0.
- A new system CLI option ``--active`` is added to the - A new system CLI option ``--active`` is added to the
:command:`load-import` command to allow the import into the :command:`load-import` command to allow the import into the
SystemController /opt/dc-vault/loads. The purpose of this is to allow System Controller /opt/dc-vault/loads. The purpose of this is to allow
Redfish install of subclouds referencing a single full copy of the Redfish install of subclouds referencing a single full copy of the
**bootimage.iso** at /opt/dc-vault/loads. \(Previously, the full **bootimage.iso** at /opt/dc-vault/loads. \(Previously, the full
**bootimage.iso** was duplicated for each :command:`subcloud add` **bootimage.iso** was duplicated for each :command:`subcloud add`
@@ -78,15 +78,15 @@ subcloud, the subcloud installation has these phases:
.. note:: .. note::
Do not power off the servers. The host portion of the server can be Do not power off the servers. The host portion of the server can be
powered off, but the |BMC| portion of the server must be powered and powered off, but the |BMC| portion of the server must be powered and
accessible from the SystemController. accessible from the System Controller.
There is no need to wipe the disks. There is no need to wipe the disks.
.. note:: .. note::
The servers require connectivity to a gateway router that provides IP The servers require connectivity to a gateway router that provides IP
routing between the subcloud management subnet and the SystemController routing between the subcloud management subnet and the System Controller
management subnet, and between the subcloud |OAM| subnet and the management subnet, and between the subcloud |OAM| subnet and the
SystemController subnet. System Controller subnet.
#. Create the install-values.yaml file and use the content to pass the file #. Create the install-values.yaml file and use the content to pass the file
into the :command:`dcmanager subcloud add` command, using the into the :command:`dcmanager subcloud add` command, using the
@@ -156,7 +156,7 @@ subcloud, the subcloud installation has these phases:
# boot_device: "/dev/disk/by-path/pci-0000:00:1f.2-ata-1.0" # boot_device: "/dev/disk/by-path/pci-0000:00:1f.2-ata-1.0"
#. At the SystemController, create a #. At the System Controller, create a
/home/sysadmin/subcloud1-bootstrap-values.yaml overrides file for the /home/sysadmin/subcloud1-bootstrap-values.yaml overrides file for the
subcloud. subcloud.
@@ -275,7 +275,7 @@ subcloud, the subcloud installation has these phases:
The :command:`dcmanager subcloud add` command can take up to ten minutes to The :command:`dcmanager subcloud add` command can take up to ten minutes to
complete. complete.
#. At the Central Cloud / SystemController, monitor the progress of the #. At the Central Cloud / System Controller, monitor the progress of the
subcloud install, bootstrapping, and deployment by using the deploy status subcloud install, bootstrapping, and deployment by using the deploy status
field of the :command:`dcmanager subcloud list` command. field of the :command:`dcmanager subcloud list` command.

2
doc/source/dist_cloud/installing-a-subcloud-without-redfish-platform-management-service.rst
View File

@@ -32,7 +32,7 @@ subcloud, the subcloud installation process has two phases:
.. note:: .. note::
After a successful remote installation of a subcloud in a Distributed Cloud After a successful remote installation of a subcloud in a Distributed Cloud
system, a subsequent remote reinstallation fails because of an existing ssh system, a subsequent remote reinstallation fails because of an existing ssh
key entry in the /root/.ssh/known\_hosts on the SystemController. In this key entry in the /root/.ssh/known\_hosts on the System Controller. In this
case, delete the host key entry, if present, from /root/.ssh/known\_hosts case, delete the host key entry, if present, from /root/.ssh/known\_hosts
on the System Controller before doing reinstallations. on the System Controller before doing reinstallations.

2
doc/source/dist_cloud/installing-and-provisioning-a-subcloud.rst
View File

@@ -16,7 +16,7 @@ Platform Management Service.
.. note:: .. note::
Each subcloud must be on a separate management subnet \(different from the Each subcloud must be on a separate management subnet \(different from the
SystemController and from any other subclouds\). System Controller and from any other subclouds\).
.. _installing-and-provisioning-a-subcloud-section-orn-jkf-t4b: .. _installing-and-provisioning-a-subcloud-section-orn-jkf-t4b:

6
doc/source/dist_cloud/managing-ldap-linux-user-accounts-on-the-system-controller.rst
View File

@@ -7,10 +7,10 @@ Managing LDAP Linux User Accounts on the System Controller
========================================================== ==========================================================
In a |prod-dc| system, |LDAP| Linux user accounts are managed centrally In a |prod-dc| system, |LDAP| Linux user accounts are managed centrally
on the SystemController. on the System Controller.
You can only add/modify/delete |LDAP| users on the SystemController. Any user You can only add/modify/delete |LDAP| users on the System Controller. Any user
account modifications done on the SystemController will be available across all account modifications done on the System Controller will be available across all
subclouds. subclouds.
For more information, see |sec-doc|: :ref:`Local LDAP Linux User Accounts For more information, see |sec-doc|: :ref:`Local LDAP Linux User Accounts

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

@@ -2,9 +2,9 @@
.. ziu1597089603252 .. ziu1597089603252
.. _robust-error-handling-during-an-orchestrated-upgrade: .. _robust-error-handling-during-an-orchestrated-upgrade:
==================================================== =============================================
Robust Error Handling During An Orchestrated Upgrade Error Handling During An Orchestrated Upgrade
==================================================== =============================================
This section describes the errors you may encounter during an orchestrated This section describes the errors you may encounter during an orchestrated
upgrade and the steps you can use to troubleshoot the errors. upgrade and the steps you can use to troubleshoot the errors.
@@ -28,10 +28,16 @@ If a failure occurs, use the following general steps:
During the Installation or Data Migration of N+1 Load on a Subcloud During the Installation or Data Migration of N+1 Load on a Subcloud
<failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud>`. <failure-during-the-installation-or-data-migration-of-n+1-load-on-a-subcloud>`.
#. Rerun the orchestrated upgrade. For more information, see :ref:`Distributed #. Retry the orchestrated upgrade. For more information, see :ref:`Distributed
Upgrade Orchestration Process Using the CLI Upgrade Orchestration Process Using the CLI
<distributed-upgrade-orchestration-process-using-the-cli>`. <distributed-upgrade-orchestration-process-using-the-cli>`.
.. note::
Orchestrated upgrade can be retried for a group of failed subclouds that
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:: .. seealso::
:ref:`Failure Prior to the Installation of N+1 Load on a Subcloud :ref:`Failure Prior to the Installation of N+1 Load on a Subcloud

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

@@ -30,11 +30,9 @@ for resources of the Keystone Identity Service \(see :ref:`Table 2
+=============================+==============================================================================================================================================================================================================================================================================================================================================================+ +=============================+==============================================================================================================================================================================================================================================================================================================================================================+
| DNS IP addresses | Subclouds use the DNS servers specified at the System Controller. | | DNS IP addresses | Subclouds use the DNS servers specified at the System Controller. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| SNMP community and trapdest | Subclouds use the SNMP alarm trap and destination settings specified at the System Controller, for example using the :command:`system snmp-comm-add`, :command:`system snmp-comm-delete`, and :command:`system snmp-trapdest-add` commands. A subcloud may use additional local settings; if present, these are not synchronized with 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. | | **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 digital certificates installed on the System Controller using the :command:`system certificate-install` command. | | Certificates | Subclouds use the Trusted |CA| certificates installed on the System Controller using the :command:`system certificate-install -m ssl_ca` command. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

14
doc/source/dist_cloud/updating-docker-registry-credentials-on-a-subcloud.rst
View File

@@ -6,26 +6,26 @@
Update Docker Registry Credentials on a Subcloud Update Docker Registry Credentials on a Subcloud
================================================ ================================================
On a subcloud that uses the systemController's docker registry On a subcloud that uses the System Controller's Docker registry
(registry.central) as its install registry, one should use the (registry.central) as its install registry, you should use the
systemController's sysinv service credentials for accessing registry.central. System Controller's sysinv service credentials for accessing registry.central.
This makes access to registry.central independent of changes to the Distributed This makes access to registry.central independent of changes to the Distributed
Cloud's keystone admin user password. Cloud's Keystone admin user password.
Use the following procedure to update the install registry credentials on the Use the following procedure to update the install registry credentials on the
subcloud to the sysinv service credentials of the systemController. subcloud to the sysinv service credentials of the System Controller.
.. rubric:: |proc| .. rubric:: |proc|
.. _updating-docker-registry-credentials-on-a-subcloud-steps-ywx-wyt-kmb: .. _updating-docker-registry-credentials-on-a-subcloud-steps-ywx-wyt-kmb:
#. On the SystemController, get the password for the sysinv services. #. On the System Controller, get the password for the sysinv services.
.. code-block:: none .. code-block:: none
$ keyring get sysinv services $ keyring get sysinv services
#. On each subcloud, run the following script to update the docker registry #. On each subcloud, run the following script to update the Docker registry
credentials to sysinv: credentials to sysinv:
.. code-block:: none .. code-block:: none

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

@@ -6,7 +6,7 @@
Upgrade Management Overview Upgrade Management Overview
=========================== ===========================
You can upgrade |prod|'s |prod-dc|'s SystemController, and subclouds with a new You can upgrade |prod|'s |prod-dc|'s System Controller, and subclouds with a new
release of |prod| software. release of |prod| software.
.. rubric:: |context| .. rubric:: |context|
@@ -14,7 +14,7 @@ release of |prod| software.
.. note:: .. note::
Backup all yaml files that are updated using the Redfish Platform Backup all yaml files that are updated using the Redfish Platform
Management service. For more information, see, :ref:`Installing a Subcloud Management service. For more information, see :ref:`Installing a Subcloud
Using Redfish Platform Management Service Using Redfish Platform Management Service
<installing-a-subcloud-using-redfish-platform-management-service>`. <installing-a-subcloud-using-redfish-platform-management-service>`.
@@ -25,13 +25,13 @@ follows:
.. _upgrade-management-overview-ol-uqv-p24-3mb: .. _upgrade-management-overview-ol-uqv-p24-3mb:
#. To upgrade the |prod-dc| system, you must first upgrade the #. To upgrade the |prod-dc| system, you must first upgrade the
SystemController. See, :ref:`Upgrading the SystemController Using the CLI System Controller. See :ref:`Upgrading the System Controller Using the CLI
<upgrading-the-systemcontroller-using-the-cli>`. <upgrading-the-systemcontroller-using-the-cli>`.
#. Use |prod-dc| Upgrade Orchestration to upgrade the subclouds. See, #. Use |prod-dc| Upgrade Orchestration to upgrade the subclouds. See
:ref:`Distributed Upgrade Orchestration Process Using the CLI <distributed-upgrade-orchestration-process-using-the-cli>`. :ref:`Distributed Upgrade Orchestration Process Using the CLI <distributed-upgrade-orchestration-process-using-the-cli>`.
#. To handle errors during an orchestrated upgrade, see :ref:`Robust Error #. To handle errors during an orchestrated upgrade, see :ref:`Error
Handling During An Orchestrated Upgrade Handling During An Orchestrated Upgrade
<robust-error-handling-during-an-orchestrated-upgrade>`. <robust-error-handling-during-an-orchestrated-upgrade>`.
@@ -47,73 +47,37 @@ The following prerequisites apply to a |prod-dc| upgrade management service.
- Run the :command:`system application-list` command to ensure that all - Run the :command:`system application-list` command to ensure that all
applications are running applications are running.
- Run the :command:`system host-list` command to list the configured - Run the :command:`system host-list` command to list the configured
hosts hosts.
- Run the :command:`dcmanager subcloud list` command to list the - Run the :command:`dcmanager subcloud list` command to list the
subclouds subclouds.
- Run the :command:`kubectl get pods --all-namespaces` command to test - Run the :command:`kubectl get pods --all-namespaces` command to test
that the authentication token validates correctly that the authentication token validates correctly.
- Run the :command:`fm alarm-list` command to check the system health to - Run the :command:`fm alarm-list` command to check the system health to
ensure that there are no unexpected alarms ensure that there are no unexpected or management-affecting alarms.
- Run the :command:`kubectl get host -n deployment` command to ensure all - Run the :command:`kubectl get host -n deployment` command to ensure all
nodes in the cluster have reconciled and is set to 'true' nodes in the cluster have reconciled and is set to 'true'.
- Ensure **controller-0** is the active controller - Ensure **controller-0** is the active controller.
- The subclouds must all be |AIO-DX|, and using the Redfish - The subclouds must all be |AIO-DX|, and using the Redfish
platform management service. platform management service.
- **Remove Non GA Applications**: - **Remove Non GA Applications**:
- Use the :command:`system application-remove` and :command:`system
application-delete` commands to remove the application on the
subclouds.
- Use the following command to remove the analytics application on the - Remove any non-GA applications and
subclouds:
- :command:`system application-remove wra-analytics`
- :command:`system application-delete wra-analytics`
- Remove any non-GA applications such as Wind River Analytics, and
|prefix|-openstack, from the |prod-dc| system, if they exist. |prefix|-openstack, from the |prod-dc| system, if they exist.
- **Increase Scratch File System Size**:
- Check the size of scratch partition on both the system controller and
subclouds using the :command:`system host-fs-list` command.
.. note::
Increase in scratch filesystem size is also required on each
subcloud.
- All controller nodes and subclouds should have a minimum of 16G scratch
file system. The process of importing a new load for upgrade will
temporarily use up to 11G of scratch disk space. Use the :command:`system
host-fs-modify` command to increase scratch size on **each controller
node** and subcloud controllers as needed in preparation for software
upgrade. For example, run the following commands:
.. code-block:: none
~(keystone_admin)]$ system host-fs-modify controller-0 scratch=16
Run the :command:`fm alarm-list` command to check the system health to
ensure that there are no unexpected alarms
- For orchestrated subcloud upgrades the install-values for each subcloud
that was used for deployment must be saved and restored to the SystemController
after the SystemController upgrade.
- Run the :command:`kubectl -n kube-system get secret` command on the
SystemController before upgrading subclouds, as the docker **rvmc** image on
orchestrated subcloud upgrade tries to copy the :command:`kube-system
default-registry-key`.
.. only:: partner .. only:: partner

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

@@ -2,18 +2,18 @@
.. vco1593176327490 .. vco1593176327490
.. _upgrading-the-systemcontroller-using-the-cli: .. _upgrading-the-systemcontroller-using-the-cli:
========================================== ===========================================
Upgrade the SystemController Using the CLI Upgrade the System Controller Using the CLI
========================================== ===========================================
You can upload and apply upgrades to the SystemController in order to upgrade You can upload and apply upgrades to the System Controller in order to upgrade
the central repository, from the CLI. The SystemController can be upgraded the central repository, from the CLI. The System Controller can be upgraded
using either a manual software upgrade procedure or by using the using either a manual software upgrade procedure or by using the
non-distributed systems :command:`sw-manager` orchestration procedure. non-distributed systems :command:`sw-manager` orchestration procedure.
.. rubric:: |context| .. rubric:: |context|
Follow the steps below to manually upgrade the SystemController: Follow the steps below to manually upgrade the System Controller:
.. rubric:: |proc| .. rubric:: |proc|
@@ -30,7 +30,7 @@ Follow the steps below to manually upgrade the SystemController:
.. include:: ../_includes/upgrading-the-systemcontroller-using-the-cli.rest .. include:: ../_includes/upgrading-the-systemcontroller-using-the-cli.rest
#. Import the software release load, and copy the iso file to controller-0 \(active controller\). #. Transfer iso and signature files to controller-0 \(active controller\) and import the load.
.. code-block:: none .. code-block:: none
@@ -87,13 +87,10 @@ Follow the steps below to manually upgrade the SystemController:
.. note:: .. note::
Use the command :command:`system upgrade-start --force` to force the Use the command :command:`system upgrade-start --force` to force the
upgrades process to start and to ignore management affecting alarms. upgrade process to start and ignore non-management-affecting alarms.
This should ONLY be done if these alarms do not cause an issue for the This should ONLY be done if these alarms do not cause an issue for the
upgrades process. upgrades process.
If there are alarms present during the upgrade, subcloud load sync\_status
will display "out-of-sync".
#. Start the upgrade from controller-0. #. Start the upgrade from controller-0.
Make sure that controller-0 is the active controller, and you are logged Make sure that controller-0 is the active controller, and you are logged
@@ -113,8 +110,8 @@ Follow the steps below to manually upgrade the SystemController:
+--------------+--------------------------------------+ +--------------+--------------------------------------+
This will make a copy of the system data to be used in the upgrade. This will make a copy of the system data to be used in the upgrade.
Configuration changes are not allowed after this point until the swact to Configuration changes must not be made after this point, until the
controller-1 is completed. upgrade is completed.
The following upgrade state applies once this command is executed. Run the The following upgrade state applies once this command is executed. Run the
:command:`system upgrade-show` command to verify the status of the upgrade. :command:`system upgrade-show` command to verify the status of the upgrade.
@@ -128,11 +125,6 @@ Follow the steps below to manually upgrade the SystemController:
- Release 20.04 system data \(for example, postgres databases\) has - Release 20.04 system data \(for example, postgres databases\) has
been exported to be used in the upgrade. been exported to be used in the upgrade.
- Configuration changes must not be made after this point, until the
upgrade is completed.
As part of the upgrade, the upgrade process checks the health of the system As part of the upgrade, the upgrade process checks the health of the system
and validates that the system is ready for an upgrade. and validates that the system is ready for an upgrade.
@@ -146,8 +138,9 @@ Follow the steps below to manually upgrade the SystemController:
This should ONLY be done if these alarms do not cause an issue for the This should ONLY be done if these alarms do not cause an issue for the
upgrades process. upgrades process.
If there are alarms present during the upgrade, subcloud load The `fm alarm-list` will provide the specific alarms leading to the system
sync\_status will display "out-of-sync". health-query-upgrade alarms notes which may be blocking an orchestrated
upgrade.
On systems with Ceph storage, it also checks that the Ceph cluster is On systems with Ceph storage, it also checks that the Ceph cluster is
healthy. healthy.
@@ -313,7 +306,7 @@ Follow the steps below to manually upgrade the SystemController:
#. If using Ceph storage backend, upgrade the storage nodes one at a time. #. If using Ceph storage backend, upgrade the storage nodes one at a time.
The storage node must be locked and all OSDs must be down in order to do The storage node must be locked and all |OSDs| must be down in order to do
the upgrade. the upgrade.
@@ -323,10 +316,10 @@ Follow the steps below to manually upgrade the SystemController:
~(keystone_admin)]$ system host-lock storage-0 ~(keystone_admin)]$ system host-lock storage-0
#. Verify that the OSDs are down after the storage node is locked. #. Verify that the |OSDs| are down after the storage node is locked.
In the Horizon interface, navigate to **Admin** \> **Platform** \> In the Horizon interface, navigate to **Admin** \> **Platform** \>
**Storage Overview** to view the status of the OSDs. **Storage Overview** to view the status of the |OSDs|.
#. Upgrade storage-0. #. Upgrade storage-0.
@@ -362,7 +355,7 @@ Follow the steps below to manually upgrade the SystemController:
**800.003**. The alarm is cleared after all storage nodes are **800.003**. The alarm is cleared after all storage nodes are
upgraded. upgraded.
#. If worker nodes are present, upgrade worker hosts, serially or parallelly, #. If worker nodes are present, upgrade worker hosts, serially or in parallel,
if any. if any.
@@ -475,11 +468,3 @@ Follow the steps below to manually upgrade the SystemController:
Run the :command:`system upgrade-show` command, and the status will display Run the :command:`system upgrade-show` command, and the status will display
"no upgrade in progress". The subclouds will be out-of-sync. "no upgrade in progress". The subclouds will be out-of-sync.
.. rubric:: |postreq|
.. warning::
Do NOT delete the N load from the SystemController once the upgrade is
complete. If the load is deleted from the SystemController, you must
manually delete the N load from each subcloud.

6
doc/source/node_management/kubernetes/common_host_tasks/swacting-a-master-controller-using-horizon.rst
View File

@@ -2,9 +2,9 @@
.. fab1579714529266 .. fab1579714529266
.. _swacting-a-master-controller-using-horizon: .. _swacting-a-master-controller-using-horizon:
======================================= ===============================
Swact a Master/Controller Using Horizon Swact Controllers Using Horizon
======================================= ===============================
Swacting initiates a switch of the active/standby roles between two Swacting initiates a switch of the active/standby roles between two
controllers. controllers.

6
doc/source/node_management/kubernetes/common_host_tasks/swacting-a-master-controller-using-the-cli.rst
View File

@@ -2,9 +2,9 @@
.. qmi1579723342974 .. qmi1579723342974
.. _swacting-a-master-controller-using-the-cli: .. _swacting-a-master-controller-using-the-cli:
======================================= ===============================
Swact a Master/Controller Using the CLI Swact Controllers Using the CLI
======================================= ===============================
Swacting initiates a switch of the active/standby roles between two Swacting initiates a switch of the active/standby roles between two
controllers. controllers.

2
doc/source/node_management/kubernetes/configuring_cpu_core_assignments/configuring-cpu-core-assignments.rst
View File

@@ -6,7 +6,7 @@
Configure CPU Core Assignments Configure CPU Core Assignments
============================== ==============================
You can improve the performance of specific functions by assigning them to You can improve the performance and capacity of specific functions by assigning them more
CPU cores from the Horizon Web interface. CPU cores from the Horizon Web interface.
.. rubric:: |proc| .. rubric:: |proc|

3
doc/source/node_management/kubernetes/displaying-worker-host-information.rst
View File

@@ -6,8 +6,7 @@
Display Worker Host Information Display Worker Host Information
=============================== ===============================
You can view worker host resources from the Horizon Web interface. You can You can view worker host resources from the Horizon Web interface.
also view data interface assignments graphically from Horizon.
.. rubric:: |proc| .. rubric:: |proc|

3
doc/source/node_management/kubernetes/hardware_acceleration_devices/enabling-mount-bryce-hw-accelerator-for-hosted-vram-containerized-workloads.rst
View File

@@ -129,5 +129,6 @@ enables the Mount Bryce device.
.. rubric:: |result| .. rubric:: |result|
To set up pods using |SRIOV|, see, :ref:`Setting Up Pods to Use SRIOV <set-up-pods-to-use-sriov>`. To set up pods using |SRIOV|, see :ref:`Setting Up Pods to Use SRIOV to Access
Mount Bryce HW Accelerator <set-up-pods-to-use-sriov>`.

8
doc/source/node_management/kubernetes/hardware_acceleration_devices/n3000-overview.rst
View File

@@ -2,9 +2,9 @@
.. pis1592390220404 .. pis1592390220404
.. _n3000-overview: .. _n3000-overview:
============== ===================
N3000 Overview N3000 FPGA Overview
============== ===================
The N3000 |FPGA| |PAC| has two Intel XL710 |NICs|, memory and an Intel |FPGA|. The N3000 |FPGA| |PAC| has two Intel XL710 |NICs|, memory and an Intel |FPGA|.
@@ -29,4 +29,4 @@ perform accelerated 5G |LDPC| encoding and decoding operations.
.. seealso:: .. seealso::
:ref:`N3000 FPGA Forward Error Correction :ref:`N3000 FPGA Forward Error Correction
<n3000-fpga-forward-error-correction>`. <n3000-fpga-forward-error-correction>`

6
doc/source/node_management/kubernetes/hardware_acceleration_devices/set-up-pods-to-use-sriov.rst
View File

@@ -2,9 +2,9 @@
.. ggs1611608368857 .. ggs1611608368857
.. _set-up-pods-to-use-sriov: .. _set-up-pods-to-use-sriov:
============================ =============================================================
Set Up Pods to Use SRIOV Set Up Pods to Use SRIOV to Access Mount Bryce HW Accelerator
============================ =============================================================
You can configure pods with |SRIOV| access to a Mount Bryce device by adding the You can configure pods with |SRIOV| access to a Mount Bryce device by adding the
appropriate 'resources' request in the pod specification. appropriate 'resources' request in the pod specification.

6
doc/source/node_management/kubernetes/hardware_acceleration_devices/showing-details-for-an-fpga-device.rst
View File

@@ -2,9 +2,9 @@
.. mmu1591729910787 .. mmu1591729910787
.. _showing-details-for-an-fpga-device: .. _showing-details-for-an-fpga-device:
=============================== =========================
Show Details for an FPGA Device Show Details for a Device
=============================== =========================
Additional details are available when running the :command:`host-device-show` Additional details are available when running the :command:`host-device-show`
command in the context of an |FPGA| device. command in the context of an |FPGA| device.

6
doc/source/node_management/kubernetes/hardware_acceleration_devices/updating-an-intel-n3000-fpga-image.rst
View File

@@ -2,9 +2,9 @@
.. yui1591714746999 .. yui1591714746999
.. _updating-an-intel-n3000-fpga-image: .. _updating-an-intel-n3000-fpga-image:
================================ ==========================
Update an Intel N3000 FPGA Image Update an N3000 FPGA Image
================================ ==========================
The N3000 |FPGA| as shipped from the factory is expected to have production The N3000 |FPGA| as shipped from the factory is expected to have production
|BMC| and factory images. The following procedure describes how to update the |BMC| and factory images. The following procedure describes how to update the

5
doc/source/node_management/kubernetes/host_hardware_management/changing-hardware-components-for-a-storage-host.rst
View File

@@ -78,9 +78,6 @@ can reproduce them later.
If the host has been deleted from the Host Inventory, the host software If the host has been deleted from the Host Inventory, the host software
is reinstalled. is reinstalled.
.. From Power up the host
.. xbookref For details, see :ref:`|inst-doc| <platform-installation-overview>`.
Wait for the host to be reported as **Locked**, **Disabled**, and Wait for the host to be reported as **Locked**, **Disabled**, and
**Online**. **Online**.
@@ -108,4 +105,6 @@ can reproduce them later.
.. From If required, allocate the |OSD| and journal disk storage. .. From If required, allocate the |OSD| and journal disk storage.
.. xbooklinkFor more information, see |stor-doc|: `Provision Storage on a Storage Host <provisioning-storage-on-a-controller-or-storage-host-using-horizon>`. .. xbooklinkFor more information, see |stor-doc|: `Provision Storage on a Storage Host <provisioning-storage-on-a-controller-or-storage-host-using-horizon>`.
.. From Power up the host
.. xbookref For details, see :ref:`|inst-doc| <platform-installation-overview>`.

2
doc/source/node_management/kubernetes/host_inventory/hosts-tab.rst
View File

@@ -186,7 +186,7 @@ A sample **Hosts** tab is illustrated below:
**Swact Host** **Swact Host**
This operation is available on controller nodes only. It initiates a This operation is available on controller nodes only. It initiates a
switch of the active/standby roles between two controllers. For more switch of the active/standby roles between two controllers. For more
information, see :ref:`Swact a Master/Controller Using Horizon information, see :ref:`Swact Controllers Using Horizon
<swacting-a-master-controller-using-horizon>`. <swacting-a-master-controller-using-horizon>`.
**Unlock Host** **Unlock Host**

4
doc/source/node_management/kubernetes/host_inventory/lldp-tab.rst
View File

@@ -6,8 +6,8 @@
LLDP Tab LLDP Tab
======== ========
The **LLDP** tab on the Host Detail page presents details about the Link The **LLDP** tab on the Host Detail page presents learned details about
Layer Discovery Protocol configuration on a node. neighbors' ports though the Link Layer Discovery Protocol.
The **LLDP** tab provides the following information about each LLDP-enabled The **LLDP** tab provides the following information about each LLDP-enabled
neighbor device: neighbor device:

2
doc/source/node_management/kubernetes/index.rst
View File

@@ -89,8 +89,8 @@ Configuring CPU core assignments
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
configuring_cpu_core_assignments/changing-the-hyper-threading-status
configuring_cpu_core_assignments/configuring-cpu-core-assignments configuring_cpu_core_assignments/configuring-cpu-core-assignments
configuring_cpu_core_assignments/changing-the-hyper-threading-status
------------------------ ------------------------
Host memory provisioning Host memory provisioning

14
doc/source/node_management/kubernetes/node_interfaces/configuring-aggregated-ethernet-interfaces-using-the-cli.rst
View File

@@ -115,17 +115,3 @@ Settings <link-aggregation-settings>`.
~(keystone_admin)$ system host-if-add controller-0 -a balanced -x layer2 ae0 ae enp0s9 enp0s10 ~(keystone_admin)$ system host-if-add controller-0 -a balanced -x layer2 ae0 ae enp0s9 enp0s10
~(keystone_admin)$ system interface-datanetwork-assign controller-0 ae0 providernet-net-a ~(keystone_admin)$ system interface-datanetwork-assign controller-0 ae0 providernet-net-a
~(keystone_admin)$ system interface-datanetwork-assign controller-0 ae0 providernet-net-b ~(keystone_admin)$ system interface-datanetwork-assign controller-0 ae0 providernet-net-b
For example, to attach an aggregated Ethernet interface named **bond0** to
the platform management network, using member interfaces **enp0s8**
and **enp0s11** on **controller-0**:
.. code-block:: none
~(keystone_admin)$ system host-if-add controller-0 -c platform -a active_standby --primary-reselect failure bond0 ae enp0s8 enp0s11
~(keystone_admin)$ system interface-network-assign controller-0 bond0 mgmt
.. only:: partner
../../../_includes/configuring-aggregated-ethernet-interfaces-using-the-cli.rest

33
doc/source/node_management/kubernetes/node_interfaces/interface-ip-address-provisioning-using-the-cli.rst
View File

@@ -9,9 +9,9 @@ Interface IP Address Provisioning Using the CLI
On a network that uses static addressing, you must assign an IP address to On a network that uses static addressing, you must assign an IP address to
the interface using the :command:`system host-addr-add` command. the interface using the :command:`system host-addr-add` command.
The procedure for attaching an interface depends on the interface type. The procedure for adding an IP address depends on the interface type.
|prod| supports three types of interfaces: |prod| supports the following types of interfaces:
**Ethernet interfaces** **Ethernet interfaces**
These are created automatically for each port on the host. You must These are created automatically for each port on the host. You must
@@ -21,11 +21,32 @@ The procedure for attaching an interface depends on the interface type.
For link protection, you can create an aggregated Ethernet interface with For link protection, you can create an aggregated Ethernet interface with
two or more ports, and configure it with the interface class. two or more ports, and configure it with the interface class.
.. code-block:: none
~(keystone_admin)$ system host-if-add <hostname> -m mtu -a aemode -x txhashpolicy ifname ae <ethname1> <ethname2>
**VLAN interfaces** **VLAN interfaces**
To support multiple interfaces on the same physical Ethernet or To support multiple interfaces on the same physical Ethernet or
aggregated Ethernet interface, you can create |VLAN| interfaces and aggregated Ethernet interface, you can create |VLAN| interfaces and
configure them with the interface class. configure them with the interface class.
.. code-block:: none
~(keystone_admin)$ systemhost-if-add <hostname> -V --vlan_id -c --ifclass <interfacename> <ethname>
**Virtual Function interfaces**
You can create an SROIV VF interface on top of an existing SROIV VF
interface in order to configure a subset of virtual functions with
different drivers. For example, if the ethernet SR-IOV interface is
configured with the kernel VF driver, you can create a VF interface to
configure a subset of virtual functions with the vfio driver that can be
used with userspace libraries such as DPDK.
.. code-block:: none
~(keystone_admin)$ system host-if-add -c pci-sriov <hostname> <interfacename> vf <parentinterfacename> -N numvfs --vf-driver=drivername
Logical interfaces of network types **oam** and **mgmt** cannot be deleted. Logical interfaces of network types **oam** and **mgmt** cannot be deleted.
They can only be modified to use different physical ports when required. They can only be modified to use different physical ports when required.
@@ -55,16 +76,16 @@ They can only be modified to use different physical ports when required.
where the following options are available: where the following options are available:
**node** ``node``
The name or UUID of the worker node. The name or UUID of the worker node.
**ifname** ``ifname``
The name of the interface. The name of the interface.
**ip\_address** ``ip\_address``
An IPv4 or IPv6 address. An IPv4 or IPv6 address.
**prefix** ``prefix``
The netmask length for the address. The netmask length for the address.
#. Unlock the node and wait for it to become available. #. Unlock the node and wait for it to become available.

2
doc/source/node_management/kubernetes/node_interfaces/interface-provisioning.rst
View File

@@ -77,7 +77,7 @@ They can only be modified to use different physical ports when required.
see |planning-doc|: `Ethernet Interfaces <about-ethernet-interfaces>`. see |planning-doc|: `Ethernet Interfaces <about-ethernet-interfaces>`.
.. note:: .. note::
On the second worker and storage nodes, the Ethernet interface for the On all nodes, except for the initial controller, the Ethernet interface for the
internal management network is attached automatically to support internal management network is attached automatically to support
installation using |PXE| booting. On the initial controller node, the installation using |PXE| booting. On the initial controller node, the
interface for the internal management network is attached according to the interface for the internal management network is attached according to the

2
doc/source/node_management/kubernetes/node_interfaces/interface-settings.rst
View File

@@ -147,7 +147,7 @@ These settings are available on the **Edit Interface** and
Use an address from a pool of IPv4 addresses that has been defined Use an address from a pool of IPv4 addresses that has been defined
and associated with the data interface. and associated with the data interface.
**IPv4 Addressing Mode** **IPv4 Addressing Pool**
\(Shown only when the **IPv4 Addressing Mode** is set to **pool**\). The \(Shown only when the **IPv4 Addressing Mode** is set to **pool**\). The
pool from which to assign an IPv4 address. pool from which to assign an IPv4 address.

18
doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst
View File

@@ -17,7 +17,7 @@ Distributed Setup
----------------- -----------------
For a distributed setup, configure the **kube-apiserver**, and For a distributed setup, configure the **kube-apiserver**, and
**oidc-auth-apps** independently for each cloud, SystemController, and all **oidc-auth-apps** independently for each cloud, System Controller, and all
subclouds. For more information, see: subclouds. For more information, see:
@@ -53,21 +53,21 @@ Centralized Setup
----------------- -----------------
For a centralized setup, the **oidc-auth-apps** is configured '**only**' on For a centralized setup, the **oidc-auth-apps** is configured '**only**' on
the SystemController. The **kube-apiserver** must be configured on all the System Controller. The **kube-apiserver** must be configured on all
clouds, SystemController, and all subclouds, to point to the centralized clouds, System Controller, and all subclouds, to point to the centralized
**oidc-auth-apps** running on the SystemController. In the centralized **oidc-auth-apps** running on the System Controller. In the centralized
setup, a user logs in, authenticates, and gets an |OIDC| token from the setup, a user logs in, authenticates, and gets an |OIDC| token from the
Central SystemController's |OIDC| identity provider, and uses the |OIDC| token Central System Controller's |OIDC| identity provider, and uses the |OIDC| token
with '**any**' of the subclouds as well as the SystemController cloud. with '**any**' of the subclouds as well as the System Controller cloud.
For a centralized |OIDC| authentication setup, use the following procedure: For a centralized |OIDC| authentication setup, use the following procedure:
.. rubric:: |proc| .. rubric:: |proc|
#. Configure the **kube-apiserver** parameters on the SystemController and #. Configure the **kube-apiserver** parameters on the System Controller and
each subcloud during bootstrapping, or by using the **system each subcloud during bootstrapping, or by using the **system
service-parameter-add kubernetes kube\_apiserver** command after service-parameter-add kubernetes kube\_apiserver** command after
bootstrapping the system, using the SystemController's floating OAM IP bootstrapping the system, using the System Controller's floating OAM IP
address as the oidc\_issuer\_url for all clouds. address as the oidc\_issuer\_url for all clouds.
address as the oidc\_issuer\_url for all clouds. address as the oidc\_issuer\_url for all clouds.
@@ -89,7 +89,7 @@ For a centralized |OIDC| authentication setup, use the following procedure:
<configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system>` <configure-kubernetes-for-oidc-token-validation-after-bootstrapping-the-system>`
#. On the SystemController only configure the **oidc-auth-apps**. For more information, see: #. On the System Controller only configure the **oidc-auth-apps**. For more information, see:
:ref:`Configure OIDC Auth Applications <configure-oidc-auth-applications>` :ref:`Configure OIDC Auth Applications <configure-oidc-auth-applications>`

12
doc/source/updates/kubernetes/performing-an-orchestrated-upgrade-using-the-cli.rst
View File

@@ -22,12 +22,12 @@ The upgrade strategy options are shown in the following output:
~(keystone_admin)]$ sw-manager upgrade-strategy --help ~(keystone_admin)]$ sw-manager upgrade-strategy --help
usage: sw-manager upgrade-strategy [-h] ... usage: sw-manager upgrade-strategy [-h] ...
optional arguments: optional arguments:
-h, --help show this help message and exit -h, --help show this help message and exit
Software Upgrade Commands: Software Upgrade Commands:
create Create a strategy create Create a strategy
delete Delete a strategy delete Delete a strategy
apply Apply a strategy apply Apply a strategy
@@ -56,7 +56,7 @@ upgrade orchestration to orchestrate the remaining nodes of the |prod|.
- 900.201, Software upgrade auto apply in progress - 900.201, Software upgrade auto apply in progress
.. _performing-an-orchestrated-upgrade-using-the-cli-ul-qhy-q1p-v1b: .. _performing-an-orchestrated-upgrade-using-the-cli-ul-qhy-q1p-v1b:
.. rubric:: |prereq| .. rubric:: |prereq|
@@ -65,6 +65,10 @@ See :ref:`Upgrading All-in-One Duplex / Standard
controller node before doing the upgrade orchestration described below to controller node before doing the upgrade orchestration described below to
upgrade the remaining nodes of the |prod|. upgrade the remaining nodes of the |prod|.
- The subclouds must use the Redfish platform management service if it is an All-in-one Simplex subcloud.
- Duplex \(AIODX/Standard\) upgrades are supported, and they do not require remote install via Redfish.
.. rubric:: |proc| .. rubric:: |proc|
.. _performing-an-orchestrated-upgrade-using-the-cli-steps-e45-kh5-sy: .. _performing-an-orchestrated-upgrade-using-the-cli-steps-e45-kh5-sy:

6
doc/source/updates/kubernetes/performing-an-orchestrated-upgrade.rst
View File

@@ -24,7 +24,7 @@ You can perform a partially-Orchestrated Upgrade of a |prod| system using the CL
During an orchestrated upgrade, the following alarms are ignored even when During an orchestrated upgrade, the following alarms are ignored even when
strict restrictions are selected: strict restrictions are selected:
- 750.006, Automatic application re-apply is pending - 750.006, Generic alarm for any platform-managed applications as they are auto-applied
- 900.005, Upgrade in progress - 900.005, Upgrade in progress
@@ -60,7 +60,7 @@ upgrade the remaining nodes of the |prod| system.
**serial** \(default\) **serial** \(default\)
Storage hosts will be upgraded one at a time. Storage hosts will be upgraded one at a time.
**parallel** **parallel**
Storage hosts will be upgraded in parallel, ensuring that only one Storage hosts will be upgraded in parallel, ensuring that only one
storage node in each replication group is upgraded at a time. storage node in each replication group is upgraded at a time.
@@ -69,7 +69,7 @@ upgrade the remaining nodes of the |prod| system.
- worker-apply-type: - worker-apply-type:
**serial** \(default\): **serial** \(default\):
Worker hosts will be upgraded one at a time. Worker hosts will be upgraded one at a time.
**parallel** **parallel**