starlingx/docs
Code Issues Proposed changes

Add Distributed guide

Browse Source 
Some reorganization to accomodate up/down variances.
Fixed merge conflicts
Incorporated patchset 7 review comments

Signed-off-by: Rafael Jardim <rafaeljordao.jardim@windriver.com>
Change-Id: I7356e81526a94c0249526b44ce667f789245f6e2
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
This commit is contained in:
Rafael Jardim 2021-03-23 17:07:56 -03:00 committed by Ron Stone
parent f9d1b4905d
commit 96760528b1
54 changed files with 2092 additions and 110 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
doc/source/_includes/dm-doc-ref.rest Normal file
View File

5
doc/source/_includes/installing-a-subcloud-using-redfish-platform-management-service.rest Normal file
View File

@ -0,0 +1,5 @@
.. begin-context
.. end-context
.. begin-prereqs
.. end-prereqs

0
doc/source/_includes/installing-a-subcloud-without-redfish-platform-management-service.rest Normal file
View File

20
doc/source/_includes/installing-and-provisioning-a-subcloud.rest Normal file
View File

@ -0,0 +1,20 @@
.. begin-redfish-vms
For subclouds with servers that support Redfish Virtual Media Service \(version
1.2 or higher\), you can use the Central Cloud's CLI to install the ISO and
bootstrap subclouds from the Central Cloud. For more information, see
:ref:`Installing a Subcloud Using Redfish Platform Management Service
<installing-a-subcloud-using-redfish-platform-management-service>`.
For subclouds with servers that do not support Redfish Virtual Media Service,
the ISO is installed locally at the subcloud. You can use the Central Cloud's
CLI to bootstrap subclouds from the Central Cloud. For more
information, see :ref:`Installing a Subcloud Without Redfish Platform
Management Service
<installing-a-subcloud-without-redfish-platform-management-service>`.
.. end-redfish-vms
.. begin-shared-nic
.. end-shared-nic

16
doc/source/_includes/installing-and-provisioning-the-central-cloud.rest Normal file
View File

@ -0,0 +1,16 @@
.. code-block:: none
system_mode: duplex
distributed_cloud_role: systemcontroller
management_start_address: <X.Y.Z>.2
management_end_address: <X.Y.Z>.50
additional_local_registry_images:
- docker.io/starlingx/rvmc:stx.5.0-v1.0.0
- quay.io/external_storage/rbd-provisioner:v2.1.1-k8s1.11
- docker.io/starlingx/ceph-config-helper:v1.15.0
...

2
doc/source/_vendor/vendor_strings.txt
View File

@ -14,6 +14,8 @@
.. |prod-p| replace:: StarlingX Platform
.. |os-prod-hor-long| replace:: OpenStack Horizon Web Interface
.. |os-prod-hor| replace:: OpenStack Horizon
.. |prod-img| replace:: http://mirror.starlingx.cengn.ca/mirror/starlingx/
.. |prod-abbr| replace:: StX
.. Guide names; will be formatted in italics by default.
.. |node-doc| replace:: :title:`StarlingX Node Configuration and Management`

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

@ -2,7 +2,7 @@
dcmanager
=========
:command:`dcmanager` is the command-line interface for the Distributed Cloud
:command:`dcmanager` is the command-line interface for the |prod-dc|
Manager APIs. :command:`dcmanager` is applicable only in the `SystemController`
region of the central cloud in a distributed cloud configuration.

5
doc/source/fault-mgmt/kubernetes/alarms-management-for-distributed-cloud.rst → doc/source/dist_cloud/alarms-management-for-distributed-cloud.rst
View File

@ -13,8 +13,8 @@ either the CLI or the Horizon Web interface.
The System Controller polls all subclouds periodically for alarm summaries.
Alarm summaries are gathered if a subcloud is online. However, they are not
gathered for a subcloud that has never been moved to the Managed state. In
Alarm summaries are gathered provided a subcloud is online. However they are
not gathered for a subcloud that has never been moved to the Managed state. In
this case, alarm counts are not available for the subcloud and dashes are shown
instead.
@ -22,3 +22,4 @@ You can access detailed alarm information for a subcloud from the System
Controller page by clicking **Alarm and Event Details** for the subcloud from
Horizon. This action automatically switches from the interface from the System
Controller page to the subcloud page.

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

@ -0,0 +1,92 @@
.. ygm1607361314876
.. certificate-management-for-admin-rest--api-endpoints:
===================================================
Certificate Management for Admin REST API Endpoints
===================================================
All messaging between SystemControllers and Subclouds in the |prod-dc|
system uses the admin REST API service endpoints, which are all configured for
secure HTTPS.
Cloud Platform supports automated HTTPS certificate renewal for |prod-dc| admin
endpoints.
.. contents:: |minitoc|
:local:
:depth: 1
.. certificate-management-for-admin-rest--api-endpoints-section-lkn-ypk-xnb:
------------------------------------
Certificates on the SystemController
------------------------------------
In a |prod-dc| system, the HTTPS certificates for admin endpoints are
managed by Cloud Platform internally.
.. note::
All renewal operations are automatic, and no user operation is required.
For admin endpoints, the SystemControllers in a |prod-dc| system
manages the following certificates:
.. certificate-management-for-admin-rest--api-endpoints-ul-zdc-pmk-xnb:
- **DC-AdminEp-Root-CA certificate**: This certificate expires in 1825 days
\(approximately 5 years\). Renewal of this certificate starts 30 days prior to
expiry.
The Root |CA| certificate is renewed on the SystemController. When the
certificate is renewed, Cloud Platform renews the intermediate |CA|
certificates for all subclouds.
- **DC-AdminEp-Intermediate-CA certificate for 'each' subcloud**: This
certificate expires in 365 days. Renewal of this certificate starts 30 days
prior to expiry. This certificate is used for all subclouds that are unmanaged.
- **DC-AdminEp-endpoint**: This certificate expires in 180 days. Renewal of
this certificate starts 30 days prior to expiry.
.. certificate-management-for-admin-rest--api-endpoints-section-qdd-xpk-xnb:
----------------------------
Certificates on the Subcloud
----------------------------
For admin endpoints, the subcloud controllers manage the following certificates:
.. certificate-management-for-admin-rest--api-endpoints-ul-x51-3qk-xnb:
- **DC-AdminEp-Intermediate-CA certificate**: The intermediate CA certificate
for a subcloud is renewed on the SystemController. It is sent to the
subcloud using a Rest API. Therefore, a subcloud needs to be online to
receive the renewed certificate.
If the subcloud is offline at the time when the subcloud intermediate |CA|
certificate is renewed, the subcloud status **dc-cert** displays
"out-of-sync". Certificate renewal continues once the subcloud is online.
When renewal completes, the status changes to "in-sync". Subclouds start
admin endpoint certificate renewal once subcloud intermediate |CA|
certificate renewal is complete.
- **DC-AdminEp certificate for the Subcloud**: This certificate expires in
180 days. Renewal of this certificate starts 30 days prior to expiry.
When the admin endpoint certificate is renewed, a new |TLS| certificate is
generated. The new |TLS| certificate is used to provide |TLS| termination.
The SystemController audits subcloud AdminEp certificates daily. It also audits
subcloud admin endpoints when a subcloud becomes online or managed. If the
subcloud admin endpoint is "out-of-sync", the SystemController initiates
intermediate |CA| certificate renewal, to force subcloud renewal of the admin
endpoint certificate.

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

@ -0,0 +1,59 @@
.. xvn1592596490325
.. _changing-the-admin-password-on-distributed-cloud:
==============================================
Change the Admin Password on Distributed Cloud
==============================================
You can change the keystone admin user password across the entire |prod-dc|
system.
.. rubric:: |prereq|
Ensure that all subclouds are managed and online.
.. rubric:: |proc|
#. Change the password.
#. Do one of the following to change a keystone admin user password on
System Controller.
- In the SystemController context, select **Identity** \> **Users**.
Select **Change Password** from the **Edit** menu for the Admin user.
- From the |CLI|:
.. code-block:: none
~(keystone_admin)]$ openstack --os-region-name SystemController user password set
Respond to the prompts to complete the process.
#. Source the script /etc/platform/openrc if you will continue to use the
environment from the previous |CLI| command.
.. code-block:: none
$ source /etc/platform/openrc
~(keystone_admin)]$
#. After five minutes, lock and then unlock each controller in the System
Controller.
#. Lock and then unlock each controller in each subcloud.
.. note::
In a subcloud, if the |CLI| command returns an authentication error after
you source the script /etc/platform/openrc, you can verify the password
on the subcloud by using the command :command:`env \| grep
OS\_PASSWORD`. If it returns the old password, you will need to run the
command :command:`keyring set CGCS admin` and provide the new admin
password.

97
doc/source/dist_cloud/cli-commands-for-alarms-management.rst Normal file
View File

@ -0,0 +1,97 @@
.. hmg1558616220923
.. _cli-commands-for-alarms-management:
==================================
CLI Commands for Alarms Management
==================================
You can use the |CLI| to review alarm summaries for the |prod-dc|.
.. _cli-commands-for-alarms-management-ul-ncv-m4y-fdb:
- To show the status of all subclouds, as well as a summary count of alarms
and warnings for each one, use the :command:`alarm summary` command.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager alarm summary
+------------+-----------------+--------------+--------------+----------+----------+
| NAME | CRITICAL_ALARMS | MAJOR_ALARMS | MINOR_ALARMS | WARNINGS | STATUS |
+------------+-----------------+--------------+--------------+----------+----------+
| subcloud-5 | 0 | 2 | 0 | 0 | degraded |
| subcloud-1 | 0 | 0 | 0 | 0 | OK |
+------------+-----------------+--------------+--------------+----------+----------+
System Controller alarms and warnings are not included.
The status is one of the following:
**OK**
There are no alarms or warnings, or only warnings.
**degraded**
There are minor or major alarms.
**critical**
There are critical alarms.
- To show the count of alarms and warnings for the System Controller, use the
:command:`alarm-summary` command.
For example:
.. code-block:: none
~(keystone_admin)]$ fm alarm-summary
+-----------------+--------------+--------------+----------+
| Critical Alarms | Major Alarms | Minor Alarms | Warnings |
+-----------------+--------------+--------------+----------+
| 0 | 0 | 0 | 0 |
+-----------------+--------------+--------------+----------+
The following command is equivalent to the :command:`fm alarm-summary`,
providing a count of alarms and warnings for the System Controller:
- :command:`fm --os-region-name RegionOne alarm-summary`
- To show the alarm and warning count for a specific subcloud only, add the
--os-region-name parameter and supply the region name:
For example:
.. code-block:: none
~(keystone_admin)]$ fm --os-region-name subcloud2 --os-auth-url http://192.168.121.2:5000/v3 alarm-summary
+-----------------+--------------+--------------+----------+
| Critical Alarms | Major Alarms | Minor Alarms | Warnings |
+-----------------+--------------+--------------+----------+
| 0 | 0 | 0 | 0 |
+-----------------+--------------+--------------+----------+
- To list the alarms for a subcloud:
.. code-block:: none
~(keystone_admin)]$ fm --os-region-name subcloud2 --os-auth-url http://192.168.121.2:5000/v3 alarm-list
+----------+--------------------------------------------+-------------------+----------+-------------------+
| Alarm ID | Reason Text | Entity ID | Severity | Time Stamp |
+----------+--------------------------------------------+-------------------+----------+-------------------+
| 250.001 | controller-0 Configuration is out-of-date. | host=controller-0 | major | 2018-02-06T21:37: |
| | | | | 32.650217 |
| | | | | |
| 250.001 | controller-1 Configuration is out-of-date. | host=controller-1 | major | 2018-02-06T21:37: |
| | | | | 29.121674 |
| | | | | |
+----------+--------------------------------------------+-------------------+----------+-------------------+

149
doc/source/dist_cloud/creating-subcloud-groups.rst Normal file
View File

@ -0,0 +1,149 @@
.. enf1600200276330
.. _creating-subcloud-groups:
======================
Create Subcloud Groups
======================
When a subcloud is created it is automatically added to the 'Default' subcloud
group, unless the group is specified. Subclouds can be associated with a
particular group when they are created, and that association can be changed to
a different subcloud group, if required.
.. rubric:: |context|
You can use |CLI| commands to add new subcloud groups, list, update or delete
subcloud groups. The |CLI| commands for managing subcloud groups are:
.. _creating-subcloud-groups-ul-fvw-cj4-3jb:
:command:`dcmanager subcloud-group add`:
Adds a new subcloud group.
:command:`dcmanager subcloud-group delete`:
Deletes subcloud group details from the database.
.. note::
The 'Default' subcloud group cannot be deleted
:command:`dcmanager subcloud-group list`:
Lists subcloud groups.
:command:`dcmanager subcloud-group list-subclouds`:
List subclouds referencing a subcloud group.
:command:`dcmanager subcloud-group show`:
Shows the details of a subcloud group.
:command:`dcmanager subcloud-group update`:
Updates attributes of a subcloud group.
.. note::
The name of the 'Default' subcloud group cannot be changed
.. rubric:: |proc|
- To create a subcloud group, use the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group add --name <<group>>
usage: dcmanager subcloud-group add [-h] [-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width <integer>]
[--fit-width] [--print-empty] [--noindent]
[--prefix PREFIX] --name NAME
[--description DESCRIPTION]
[--update_apply_type UPDATE_APPLY_TYPE]
[--max_parallel_subclouds MAX_PARALLEL_SUBCLOUDS]
For example,
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group add --name <Group1>
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| id | 1 |
| name | Group1 |
| description | No description provided |
| update apply type | parallel |
| max parallel subclouds | 20 |
| created_at | 2020-09-15 19:03:30.050353 |
| updated_at | None |
+------------------------+----------------------------+
To create an upgrade strategy, if required, use the :command:`dcmanager
upgrade-strategy create`, :command:`dcmanager patch-strategy create`, or
:command:`dcmanager fw-update-strategy create` commands. For more
information, see :ref:`Managing Subcloud Groups
<managing-subcloud-groups>`.
- To list subcloud groups, use the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group list
To list subclouds referencing a subcloud group, use the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group list-subclouds
For example,
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group list-subclouds Group1
+--+------+----+----+-------+-------+------+-----------+-----------+-------------+-----------+------------+------------+------+----------+----------+
|id|name |desc|loc.|sof.ver|mgmnt |avail |deploy_stat|mgmt_subnet|mgmt_start_ip|mgmt_end_ip|mgmt_gtwy_ip|sysctrl_gtwy|grp_id|created_at|updated_at|
+--+------+----+----+-------+-------+------+-----------+-----------+-------------+-----------+------------+------------+------+----------+----------+
|3 |subcl1|None|None|20.06 |managed|online|complete |fd01:12::0.|fd01:12::2 |fd01:12::11|fd01:12::1 |fd01:11::1 | 2 |2021-01-09|2021-01-12|
|4 |subcl2|None|None|20.06 |managed|online|complete |fd01:13::0.|fd01:13::2 |fd01:13::11|fd01:13::1 |fd01:11::1 | 2 |2021-01-09|2021-01-12|
+--+------+----+----+-------+-------+------+-----------+-----------+-------------+-----------+------------+------------+------+----------+----------+
- To show the details of a subcloud group, use the following command:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group show
For example,
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud-group show Group1
+------------------------+----------------------------+
| Field | Value |
+------------------------+----------------------------+
| id | 2 |
| name | Group1 |
| description | subcloud 3 and 4 |
| update apply type | parallel |
| max parallel subclouds | 2 |
| created_at | 2021-01-12 18:57:38.382269 |
| updated_at | None |
+------------------------+----------------------------+
- To update the attributes and associate a subcloud with a specific subcloud
group, use the following command, for example:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud update --group Group1 Subcloud1
usage: dcmanager subcloud update [-h] [-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width <integer>]
[--fit-width] [--print-empty] [--noindent]
[--prefix PREFIX] [--description DESCRIPTION]
[--location LOCATION] [--group GROUP]
[--install-values INSTALL_VALUES]
[--bmc-password BMC_PASSWORD]
subcloud

104
doc/source/dist_cloud/distributed-cloud-architecture.rst Normal file
View File

@ -0,0 +1,104 @@
.. bwx1558617101415
.. _distributed-cloud-architecture:
==============================
Distributed Cloud Architecture
==============================
A |prod-dc| system consists of a Central Cloud and one or more subclouds
connected to the Central Cloud over L3 networks.
The Central Cloud has two regions: RegionOne, used to manage the nodes in the
Central Cloud, and SystemController, used to manage the subclouds in the
|prod-dc| system. You can select RegionOne or SystemController regions from the
Horizon Web interface or by setting the <OS\_REGION\_NAME> environment variable
if using the CLI.
**Central Cloud**
The Central Cloud provides a RegionOne region for managing the physical
platform of the Central Cloud and the SystemController region for managing
and orchestrating over the subclouds.
The Central Cloud does not support worker hosts. All worker functions are
performed at the subcloud level.
**RegionOne**
RegionOne is the name of the access mode, or region, for managing the
Central Cloud's physical platform.
**System Controller**
The System Controller access mode, or region, for managing subclouds is
SystemController.
You can use the System Controller to add subclouds, synchronize select
configuration data across all subclouds and monitor subcloud operations and
alarms. You can also access the individual subclouds through the single
central Horizon interface at the Central Cloud to perform subcloud-specific
operations such as configuring and managing the subclouds' host nodes and
containers. System software updates for the subclouds are also centrally
managed and applied from the System Controller.
DNS and other select configuration settings are centrally managed at the
System Controller and pushed to the subclouds in parallel to maintain
synchronization across the |prod-dc|.
**Subclouds**
The subclouds are |prod| instances used to host containerized applications.
Any type of |prod| deployment configuration, i.e. simplex, duplex or
standard with or without storage nodes, can be used for a subcloud.
Alarms raised at the subclouds are sent to the System Controller for
central reporting.
.. note::
Services in a Subcloud authenticate against their local Identity
Provider only \(i.e. Keystone for StarlingX and Kubernetes Service
Accounts for Kubernetes\). This allows the subcloud to not only be
autonomous in the face of disruptions with the Central Region, but also
allows the subcloud to improve service performance since authentication
is localized within the subcloud.
Each subcloud can be in a Managed or Unmanaged state.
**Managed**
When a subcloud is in the Managed state, it is updated \(synchronized\)
immediately with configuration changes made at the System Controller.
This is the normal operating state. Updates may be delayed slightly
depending on network conditions.
**Unmanaged**
When the subcloud is in an Unmanaged state, configuration changes are
queued at the System Controller. They are sent to the subcloud when the
subcloud is returned to a Managed state. The Unmanaged state is used to
disconnect the subcloud from synchronization operations for local
maintenance. Alarms generated by the subcloud are still sent to the
System Controller.
**Networks**
Subclouds are connected to the System Controller over L3 networks. Because
each subcloud is on a separate L3 subnet, the management and PXE boot L2
networks are local to the subclouds and not connected via L2 to the Central
Cloud; they are only connected via L3 routing.
The settings required to connect a subcloud to the System Controller are
specified when a subcloud is defined. For more information, see
:ref:`Installing a Subcloud Without Redfish Platform Management Service
<installing-a-subcloud-without-redfish-platform-management-service>`.
No additional platform configuration is required to establish network
communications. However, third-party routers are required to complete the
L3 connections. The routers must be configured independently according to
OEM instructions.
All messaging between SystemControllers and Subclouds uses the **admin**
REST API service endpoints which, in this distributed cloud environment,
are all configured for secure HTTPS. Certificates for these HTTPS
connections are managed internally by |prod|.
.. xbooklink For more information, see, :ref:`Certificate Management for Admin
REST API Endpoints <certificate-management-for-admin-rest-endpoints>`.

82
doc/source/dist_cloud/distributed-cloud-ports-reference.rst Normal file
View File

@ -0,0 +1,82 @@
.. sac1584464416105
.. _distributed-cloud-ports-reference:
=================================
Distributed Cloud Ports Reference
=================================
A number of ports must be available for various |prod-dc| components to
function correctly.
.. _distributed-cloud-ports-reference-table-mxl-qhh-blb:
.. table:: Table 1. |prod-dc| port requirements
:widths: auto
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| Protocol | Port | Description | Initiator | Destination | Notes |
+==========+=======+============================+==================================================+=====================================+=========================================+
| tcp | 22 | ssh | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 123 | ntp | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 161 | snmp | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 2222 | SM | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 2223 | SM | Not used between System Controller and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 4546 | stx-nfv | System Controller | Subclouds | vim-restapi |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 5001 | keystone-api | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 5492 | patching-api | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 6386 | sysinv-api | System Controller | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 6443 | K8s API server | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 7778 | stx-ha | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8443 | horizon https | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8080 | horizon http | Not used between SystemController and Subclouds | Not required if using https | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8119 | stx-distcloud | Not used between SystemController and Subclouds | dcmanager-api | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 15491 | stx-update | Not used between SystemController and Subclouds | only required for system controller | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 18003 | stx-fault | SystemController | Subclouds | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| icmp | icmp | | | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 9312 | barbican | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 319 | PTP | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 320 | PTP | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp/udp | 636 | LDAPS | Subcloud | Windows AD server | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 389 | LDAP | Subcloud | Windows AD server | Not required if using LDAPs |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp/udp | 30555 | OIDC Client | Subcloud | | Used by remote user when authenticating |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp/udp | 30556 | DEC OIDC Provider | Subcloud | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8220 | Dist. cloud | SystemController | Subclouds | dcdbsync-api |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 31001 | Elastic \(using NodePort\) | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 9001 | Docker registry | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 9002 | Registry token server | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| udp | 162 | snmp trap | Subcloud | DC | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
| tcp | 8443 | https | Not used between SystemController and Subclouds | | |
+----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.5 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 151 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 113 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

62
doc/source/dist_cloud/index.rst Normal file
View File

@ -0,0 +1,62 @@
=================
Distributed Cloud
=================
------------
Introduction
------------
.. toctree::
:maxdepth: 1
:caption: Contents:
overview-of-distributed-cloud
distributed-cloud-architecture
shared-configurations
regionone-and-systemcontroller-modes
alarms-management-for-distributed-cloud
cli-commands-for-alarms-management
------------
Installation
------------
.. toctree::
:maxdepth: 1
:caption: Contents:
installing-and-provisioning-the-central-cloud
installing-and-provisioning-a-subcloud
installing-a-subcloud-using-redfish-platform-management-service
installing-a-subcloud-without-redfish-platform-management-service
---------
Operation
---------
.. toctree::
:maxdepth: 1
:caption: Contents:
monitoring-subclouds-using-horizon
managing-subclouds-using-the-cli
managing-subcloud-groups
creating-subcloud-groups
ochestration-strategy-using-subcloud-groups
switching-to-a-subcloud-from-the-system-controller
synchronization-monitoring-and-control
managing-ldap-linux-user-accounts-on-the-system-controller
changing-the-admin-password-on-distributed-cloud
updating-docker-registry-credentials-on-a-subcloud
--------
Appendix
--------
.. toctree::
:maxdepth: 1
:caption: Contents:
distributed-cloud-ports-reference
certificate-management-for-admin-rest--api-endpoints

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

@ -0,0 +1,378 @@
.. vbb1579292724479
.. _installing-a-subcloud-using-redfish-platform-management-service:
===============================================================
Installing a Subcloud Using Redfish Platform Management Service
===============================================================
For subclouds with servers that support Redfish Virtual Media Service \(version
1.2 or higher\), you can use the Central Cloud's CLI to install the ISO and
bootstrap the subclouds from the Central Cloud.
.. _installing-a-subcloud-using-redfish-platform-management-service-section-N10022-N1001F-N10001:
.. rubric:: |context|
After physically installing the hardware and network connectivity of a
subcloud, the subcloud installation has these phases:
- Executing the :command:`dcmanager subcloud add` command in the Central Cloud:
- Uses Redfish Virtual Media Service to remote install the ISO on
controller-0 in the subcloud
- Uses Ansible to bootstrap |prod-long| on controller-0 in
the subcloud
.. note::
After a successful remote installation of a subcloud in a Distributed Cloud
system, a subsequent remote reinstallation fails because of an existing ssh
key entry in the /root/.ssh/known\_hosts on the SystemController. In this
case, delete the host key entry, if present, from /root/.ssh/known\_hosts
on the SystemController before doing reinstallations.
.. rubric:: |prereq|
.. _installing-a-subcloud-using-redfish-platform-management-service-ul-g5j-3f3-qjb:
- The docker **rvmc** image needs to be added to the SystemController
bootstrap override file, docker.io/starlingx/rvmc:stx.5.0-v1.0.0.
- A new system CLI option ``--active`` is added to the
:command:`load-import` command to allow the import into the
SystemController /opt/dc-vault/loads. The purpose of this is to allow
Redfish install of subclouds referencing a single full copy of the
**bootimage.iso** at /opt/dc-vault/loads. \(Previously, the full
**bootimage.iso** was duplicated for each :command:`subcloud add`
command\).
.. note::
This is required only once and does not have to be done for every
subcloud install.
:command:`dcmanager` recognizes bootimage names ending in <.iso> and
<.sig>
For example,
.. code-block:: none
~(keystone_admin)]$ system --os-region-name SystemController load-import --active wind-river-cloud-platform-host-installer-<version>.iso wind-river-cloud-platform-host-installer-<version>.sig
In order to be able to deploy subclouds from either controller, all local
files that are referenced in the **bootstrap.yml** file must exist on both
controllers \(for example, /home/sysadmin/docker-registry-ca-cert.pem\).
.. rubric:: |proc|
#. At the subcloud location, physically install the servers and network
connectivity required for the subcloud.
.. See |inst-doc|: :ref:`Preparing Servers <preparing-servers>` for more
information.
.. note::
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
accessible from the SystemController.
There is no need to wipe the disks.
.. note::
The servers require connectivity to a gateway router that provides IP
routing between the subcloud management subnet and the SystemController
management subnet, and between the subcloud |OAM| subnet and the
SystemController subnet.
#. Create the install-values.yaml file and use the content to pass the file
into the :command:`dcmanager subcloud add` command, using the
:command:`--install-values` command option.
.. note::
If your controller is on a ZTSystems Triton server that requires a
longer timeout value, you can now use the rd.net.timeout.ipv6dad dracut
parameter to specify an increased timeout value for dracut to wait for
the interface to have carrier, and complete IPv6 duplicate address
detection |DAD|. For the ZTSystems server, this can take more than
four minutes. It is recommended to set this value to 300 seconds, by
specifying the following in the subcloud install-values.yaml file:
.. code-block:: none
rd.net.timeout.ipv6dad: 300
For example, :command:`--install-values /home/sysadmin/install-values.yaml`.
.. code-block:: none
# Specify the WRCP software version, for example '20.06' for the WRCP 20.06 release of software.
software_version: <software_version>
bootstrap_interface: <bootstrap_interface_name> # e.g. eno1
bootstrap_address: <bootstrap_interface_ip_address> # e.g.128.224.151.183
bootstrap_address_prefix: <bootstrap_netmask> # e.g. 23
# Board Management Controller
bmc_address: <BMCs_IPv4_or_IPv6_address> # e.g. 128.224.64.180
bmc_username: <bmc_username> # e.g. root
# If the subcloud's bootstrap IP interface and the system controller are not on the
# same network then the customer must configure a default route or static route
# so that the Central Cloud can login bootstrap the newly installed subcloud.
# If nexthop_gateway is specified and the network_address is not specified then a
# default route will be configured. Otherwise, if a network_address is specified then
# a static route will be configured.
nexthop_gateway: <default_route_address> for # e.g. 128.224.150.1 (required)
network_address: <static_route_address> # e.g. 128.224.144.0
network_mask: <static_route_mask> # e.g. 255.255.254.0
# Installation type codes
#0 - Standard Controller, Serial Console
#1 - Standard Controller, Graphical Console
#2 - AIO, Serial Console
#3 - AIO, Graphical Console
#4 - AIO Low-latency, Serial Console
#5 - AIO Low-latency, Graphical Console
install_type: 3
# Optional parameters defaults can be modified by uncommenting the option with a modified value.
# This option can be set to extend the installing stage timeout value
# wait_for_timeout: 3600
# Set this options for https
no_check_certificate: True
# If the bootstrap interface is a vlan interface then configure the vlan ID.
# bootstrap_vlan: <vlan_id>
# Override default filesystem device.
# rootfs_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
/home/sysadmin/subcloud1-bootstrap-values.yaml overrides file for the
subcloud.
For example:
.. code-block:: none
system_mode: simplex
name: "subcloud1"
description: "test"
location: "loc"
management_subnet: 192.168.101.0/24
management_start_address: 192.168.101.2
management_end_address: 192.168.101.50
management_gateway_address: 192.168.101.1
external_oam_subnet: 10.10.10.0/24
external_oam_gateway_address: 10.10.10.1
external_oam_floating_address: 10.10.10.12
systemcontroller_gateway_address: 192.168.204.101
docker_registries:
k8s.gcr.io:
url: registry.central:9001/k8s.gcr.io
gcr.io:
url: registry.central:9001/gcr.io
quay.io:
url: registry.central:9001/quay.io
docker.io:
url: registry.central:9001/docker.io
docker.elastic.co:
url: registry.central:9001/docker.elastic.co
defaults:
username: sysinv
password: <sysinv_password>
type: docker
Where <sysinv\_password> can be found by running the following command as
'sysadmin' on the Central Cloud:
.. code-block:: none
$ keyring get sysinv services
This configuration will install container images from the local registry on
your central cloud. The Central Cloud's local registry's HTTPS Certificate
must have the Central Cloud's |OAM| IP, **registry.local** and
**registry.central** in the certificate's SAN list. For example, a valid
certificate contains a |SAN| list:
.. code-block:: none
"DNS.1: registry.local DNS.2: registry.central IP.1: floating_management IP.2: floating_OAM"
If required, run the following command on the Central Cloud prior to
bootstrapping the subcloud to install the new certificate for the Central
Cloud with the updated |SAN| list:
.. code-block:: none
~(keystone_admin)]$ system certificate-install -m docker_registry path_to_cert
If you prefer to install container images from the default WRS AWS ECR
external registries, make the following substitutions for the
**docker\_registries** sections of the file.
.. code-block:: none
docker_registries:
defaults:
username: <your_wrs-aws.io_username>
password: <your_wrs-aws.io_password>
#. Add the subcloud using :command:`dcmanager`.
When calling the :command:`subcloud add` command, specify the install
values, the bootstrap values and the subcloud's **sysadmin** password.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud add \
--bootstrap-address <oam_ip_address_of_subclouds_controller-0 >\
--bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml \
--sysadmin-password <sysadmin_password> \
--install-values /home/sysadmin/install-values.yaml \
--bmc-password <bmc_password>
if the ``--sysadmin-password`` is not specified, you are prompted to
enter it once the full commmand is invoked. The password is masked
when it is entered.
.. code-block:: none
Enter the sysadmin password for the subcloud:
\(Optional\) The ``--bmc-password`` <password> is used for subcloud
installation, and only required if the ``--install-values`` parameter is
specified.
If the ``--bmc-password`` <password> is omitted and the
``--install-values`` option is specified the system administrator will be
prompted to enter it, following the :command:`dcmanager subcloud add`
command. This option is ignored if the ``--install-values`` option is not
specified. The password is masked when it is entered.
.. code-block:: none
Enter the bmc password for the subcloud:
You will be prompted for the |BMC| password of the subcloud. This command
will take five to ten minutes to complete.
The :command:`dcmanager subcloud add` command can take up to ten minutes to
complete.
#. At the Central Cloud / SystemController, monitor the progress of the
subcloud install, bootstrapping, and deployment by using the deploy status
field of the :command:`dcmanager subcloud list` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud list
+----+-----------+------------+--------------+---------------+---------+
| id | name | management | availability | deploy status | sync |
+----+-----------+------------+--------------+---------------+---------+
| 1 | subcloud1 | unmanaged | online | installing | unknown |
+----+-----------+------------+--------------+---------------+---------+
The **deploy status** field has the following values:
**Pre-Install**
This status indicates that the ISO for the subcloud is being updated by
the Central Cloud with the boot menu parameters, and kickstart
configuration as specified in the install-values.yaml file.
**Installing**
This status indicates that the subcloud's ISO is being installed from
the Central Cloud to the subcloud using the Redfish Virtual Media
service on the subcloud's |BMC|.
**Bootstrapping**
This status indicates that the Ansible bootstrap of |prod-long|
software on the subcloud's controller-0 is in progress.
**Complete**
This status indicates that subcloud deployment is complete.
The subcloud install, bootstrapping and deployment can take up to 30
minutes.
.. caution::
If there is an installation failure, or a failure during bootstrapping,
you must delete the subcloud before re-adding it, using the
:command:`dcmanager subcloud add` command. For more information on
deleting, managing or unmanaging a subcloud, see :ref:`Managing
Subclouds Using the CLI <managing-subclouds-using-the-cli>`.
If there is a deployment failure, do not delete the subcloud, use the
:command:`subcloud reconfig` command, to reconfigure the subcloud. For
more information, see :ref:`Managing Subclouds Using the CLI
<managing-subclouds-using-the-cli>`.
#. You can also monitor detailed logging of the subcloud installation,
bootstrapping and deployment by monitoring the following log files on the
active controller in the Central Cloud.
/var/log/dcmanager/<subcloud\_name>\_install\_<date\_stamp>.log.
/var/log/dcmanager/<subcloud\_name>\_bootstrap\_<date\_stamp>.log.
For example:
.. code-block:: none
controller-0:/home/sysadmin# tail /var/log/dcmanager/subcloud1_install_2019-09-23-19-19-42.log
TASK [wait_for] ****************************************************************
ok: [subcloud1]
controller-0:/home/sysadmin# tail /var/log/dcmanager/subcloud1_bootstrap_2019-09-23-19-03-44.log
k8s.gcr.io: {password: secret, url: null}
quay.io: {password: secret, url: null}
)
TASK [bootstrap/bringup-essential-services : Mark the bootstrap as completed] ***
changed: [subcloud1]
PLAY RECAP *********************************************************************
subcloud1 : ok=230 changed=137 unreachable=0 failed=0
.. rubric:: |postreq|
.. _installing-a-subcloud-using-redfish-platform-management-service-ul-ixy-lpv-kmb:
- Provision the newly installed and bootstrapped subcloud. For detailed
|prod| deployment procedures for the desired deployment configuration of
the subcloud, see the post-bootstrap steps of |inst-doc|.
- Check and update docker registry credentials on the subcloud:
.. code-block:: none
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.
- For more information on bootstrapping and deploying |inst-doc|.

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

@ -0,0 +1,321 @@
.. pja1558616715987
.. _installing-a-subcloud-without-redfish-platform-management-service:
==============================================================
Install a Subcloud Without Redfish Platform Management Service
==============================================================
For subclouds with servers that do not support Redfish Virtual Media Service,
the ISO is installed locally at the subcloud. You can use the Central Cloud's
CLI to bootstrap subclouds from the Central Cloud.
.. _installing-a-subcloud-without-redfish-platform-management-service-section-N10027-N10024-N10001:
.. rubric:: |context|
After physically installing the hardware and network connectivity of a
subcloud, the subcloud installation process has two phases:
.. _installing-a-subcloud-without-redfish-platform-management-service-ul-fmx-jpl-mkb:
- Installing the ISO on controller-0; this is done locally at the subcloud by
using either, a bootable USB device, or a local PXE boot server
- Executing the :command:`dcmanager subcloud add` command in the Central
Cloud that uses Ansible to bootstrap |prod-long| on controller-0 in
the subcloud
.. note::
After a successful remote installation of a subcloud in a Distributed Cloud
system, a subsequent remote reinstallation fails because of an existing ssh
key entry in the /root/.ssh/known\_hosts on the SystemController. In this
case, delete the host key entry, if present, from /root/.ssh/known\_hosts
on the System Controller before doing reinstallations.
.. rubric:: |prereq|
.. _installing-a-subcloud-without-redfish-platform-management-service-ul-g5j-3f3-qjb:
- You must have downloaded update-iso.sh from |dnload-loc|.
- In order to be able to deploy subclouds from either controller, all local
files that are referenced in the **bootstrap.yml** file must exist on both
controllers \(for example, /home/sysadmin/docker-registry-ca-cert.pem\).
.. rubric:: |proc|
#. At the subcloud location, physically install the servers and network
connectivity required for the subcloud.
.. See |inst-doc|: :ref:`Preparing Servers <preparing-servers>`.
.. note::
The servers require connectivity to a gateway router that provides IP
routing between the subcloud management subnet and the System
Controller management subnet, and between the subcloud OAM subnet and
the System Controller subnet.
#. Update the ISO image to modify installation boot parameters \(if
required\), automatically select boot menu options and add a kickstart file
to automatically perform configurations such as configuring the initial IP
Interface for bootstrapping.
For subclouds, the initial IP Interface should be the planned |OAM| IP
Interface for the subcloud.
Use the update-iso.sh script from |dnload-loc|. The script is used as
follows:
.. code-block:: none
update-iso.sh -i <input bootimage.iso> -o <output bootimage.iso>
[ -a <ks-addon.cfg> ] [ -p param=value ]
[ -d <default menu option> ] [ -t <menu timeout> ]
-i <file>: Specify input ISO file
-o <file>: Specify output ISO file
-a <file>: Specify ks-addon.cfg file
-p <p=v>: Specify boot parameter
Examples:
-p rootfs_device=nvme0n1
-p boot_device=nvme0n1
-p rootfs_device=/dev/disk/by-path/pci-0000:00:0d.0-ata-1.0
-p boot_device=/dev/disk/by-path/pci-0000:00:0d.0-ata-1.0
-d <default menu option>:
Specify default boot menu option:
0 - Standard Controller, Serial Console
1 - Standard Controller, Graphical Console
2 - AIO, Serial Console
3 - AIO, Graphical Console
4 - AIO Low-latency, Serial Console
5 - AIO Low-latency, Graphical Console
NULL - Clear default selection
-t <menu timeout>:
Specify boot menu timeout, in seconds
The following example ks-addon.cfg, used with the -a option, sets up an
initial IP interface at boot time by defining a |VLAN| on an Ethernet
interface and has it use DHCP to request an IP address:
.. code-block:: none
#### start ks-addon.cfg
OAM_DEV=enp0s3
OAM_VLAN=1234
cat << EOF > /etc/sysconfig/network-scripts/ifcfg-$OAM_DEV
DEVICE=$OAM_DEV
BOOTPROTO=none
ONBOOT=yes
LINKDELAY=20
EOF
cat << EOF > /etc/sysconfig/network-scripts/ifcfg-$OAM_DEV.$OAM_VLAN
DEVICE=$OAM_DEV.$OAM_VLAN
BOOTPROTO=dhcp
ONBOOT=yes
VLAN=yes
LINKDELAY=20
EOF
#### end ks-addon.cfg
After updating the ISO image, create a bootable USB with the ISO or put the
ISO on a PXEBOOT server.
#. At the subcloud location, install the |prod| software from a USB
device or a |PXE| Boot Server on the server designated as controller-0.
See |inst-doc| instructions for preparing servers.
#. At the subcloud location, verify that the |OAM| interface on the subcloud
controller has been properly configured by the kickstart file added to the
ISO.
Log in to the subcloud's controller-0 and ping the Central Cloud's floating
|OAM| IP Address.
#. At the System Controller, create a
/home/sysadmin/subcloud1-bootstrap-values.yaml overrides file for the
subcloud.
For example:
.. code-block:: none
system_mode: simplex
name: "subcloud1"
description: "test"
location: "loc"
management_subnet: 192.168.101.0/24
management_start_address: 192.168.101.2
management_end_address: 192.168.101.50
management_gateway_address: 192.168.101.1
external_oam_subnet: 10.10.10.0/24
external_oam_gateway_address: 10.10.10.1
external_oam_floating_address: 10.10.10.12
systemcontroller_gateway_address: 192.168.204.101
docker_registries:
k8s.gcr.io:
url: registry.central:9001/k8s.gcr.io
gcr.io:
url: registry.central:9001/gcr.io
quay.io:
url: registry.central:9001/quay.io
docker.io:
url: registry.central:9001/docker.io
docker.elastic.co:
url: registry.central:9001/docker.elastic.co
defaults:
username: sysinv
password: <sysinv_password>
type: docker
Where <sysinv\_password\> can be found by running the following command
as 'sysadmin' on the Central Cloud:
.. code-block:: none
$ keyring get sysinv services
This configuration uses the local registry on your central cloud. If you
prefer to use the default external registries, make the following
substitutions for the **docker\_registries** and
**additional\_local\_registry\_images** sections of the file.
.. code-block:: none
docker_registries:
defaults:
username: <your_wrs-aws.io_username>
password: <your_wrs-aws.io_password>
.. note::
If you have a reason not to use the Central Cloud's local registry you
can pull the images from another local private docker registry.
#. You can use the Central Cloud's local registry to pull images on subclouds.
The Central Cloud's local registry's HTTPS certificate must have the
Central Cloud's |OAM| IP, **registry.local** and **registry.central** in the
certificate's |SAN| list. For example, a valid certificate contains a |SAN|
list **"DNS.1: registry.local DNS.2: registry.central IP.1: <floating
management\> IP.2: <floating OAM\>"**.
If required, run the following command on the Central Cloud prior to
bootstrapping the subcloud to install the new certificate for the Central
Cloud with the updated |SAN| list:
.. code-block:: none
~(keystone_admin)]$ system certificate-install -m docker_registry path_to_cert
#. Add the subcloud using :command:`dcmanager`.
When calling the :command:`subcloud add` command, specify the bootstrap
values and the subcloud's **sysadmin** password.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud add --bootstrap-address <oam ip address of subcloud's controller-0> \
--bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml \
--sysadmin-password <sysadmin_password>
You will be prompted for the Linux password of the subcloud. This command
will take five to ten minutes to complete.
#. At the Central Cloud / System Controller, monitor the progress of the
subcloud bootstrapping and deployment by using the deploy status field of
the :command:`dcmanager subcloud list` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud list
+----+-----------+------------+--------------+---------------+---------+
| id | name | management | availability | deploy status | sync |
+----+-----------+------------+--------------+---------------+---------+
| 1 | subcloud1 | unmanaged | online | complete | unknown |
+----+-----------+------------+--------------+---------------+---------+
The deploy status field has the following values:
**Bootstrapping**
This status indicates that the Ansible bootstrap of Wind River Cloud
Platform software on the subcloud's controller-0 is in progress.
**Complete**
This status indicates that subcloud deployment is complete.
The subcloud bootstrapping and deployment can take up to 30 minutes.
.. caution::
If there is a failure during bootstrapping, you must delete the
subcloud before re-adding it, using the :command:`dcmanager subcloud
add` command. For more information on deleting, managing or unmanaging
a subcloud, see :ref:`Managing Subclouds Using the CLI
<managing-subclouds-using-the-cli>`.
#. You can also monitor detailed logging of the subcloud bootstrapping and
deployment by monitoring the following log files on the active controller
in the Central Cloud.
/var/log/dcmanager/<subcloud\_name>\_bootstrap\_<date\_stamp>.log
For example:
.. code-block:: none
controller-0:/home/sysadmin# tail /var/log/dcmanager/subcloud1_bootstrap_2019-09-23-19-03-44.log
k8s.gcr.io: {password: secret, url: null}
quay.io: {password: secret, url: null}
)
TASK [bootstrap/bringup-essential-services : Mark the bootstrap as completed] ***
changed: [subcloud1]
PLAY RECAP *********************************************************************
subcloud1 : ok=230 changed=137 unreachable=0 failed=0
.. rubric:: |postreq|
.. _installing-a-subcloud-without-redfish-platform-management-service-ul-ixy-lpv-kmb:
- Provision the newly installed and bootstrapped subcloud. For detailed
|prod| deployment procedures for the desired deployment
configuration of the subcloud, see the post-bootstrap steps of |inst-doc|.
- Check and update docker registry credentials on the subcloud:
.. code-block:: none
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, ":command:`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.
- For more information on bootstrapping and deploying see |inst-doc|.

28
doc/source/dist_cloud/installing-and-provisioning-a-subcloud.rst Normal file
View File

@ -0,0 +1,28 @@
.. vdh1580229514829
.. _installing-and-provisioning-a-subcloud:
===================================
Install and Provisioning a Subcloud
===================================
You can install and provision a subcloud with or without using the Redfish
Platform Management Service.
.. include:: ../_includes/installing-and-provisioning-a-subcloud.rest
:start-after: begin-redfish-vms
:end-before: end-redfish-vms
.. note::
Each subcloud must be on a separate management subnet \(different from the
SystemController and from any other subclouds\).
.. _installing-and-provisioning-a-subcloud-section-orn-jkf-t4b:
.. only:: partner
.. include:: ../_includes/installing-and-provisioning-a-subcloud.rest
:start-after: begin-shared-nic
:end-before: end-shared-nic

54
doc/source/dist_cloud/installing-and-provisioning-the-central-cloud.rst Normal file
View File

@ -0,0 +1,54 @@
.. fkg1558616822571
.. _installing-and-provisioning-the-central-cloud:
==========================================
Install and Provisioning the Central Cloud
==========================================
Installing the Central Cloud is similar to installing a standalone |prod|
system.
.. rubric:: |context|
The Central Cloud supports either
- an |AIO|-Duplex deployment configuration
- a Standard with Dedicated Storage Nodes deployment Standard with Controller
Storage and one or more workers deployment configuration, or
- a Standard with Dedicated Storage Nodes deployment configuration.
.. rubric:: |proc|
Complete the |prod| procedure for your deployment scenario with the
modifications noted above and below.
.. xbooklink For detailed |prod| deployment procedures, see :ref:`|inst-doc|
<platform-installation-overview>`.
You will also need to make the following modification:
- when creating the user configuration overrides for the Ansible bootstrap
playbook in /home/sysadmin/localhost.yml.
Add the parameters shown in bold below to your /home/sysadmin/localhost.yml
Ansible bootstrap override file to indicate that this cloud will play the
role of the Central Cloud / System Controller
- restrict the range of addresses for the management network (using
management_start_address and management_end_address, as shown below) to
exclude the IP addresses reserved for gateway routers that provide routing
to the subclouds' management subnets.
- Also, include the container images shown in bold below in
additional\_local\_registry\_images, required for support of subcloud
installs with the Redfish Platform Management Service, and subcloud installs
using a Ceph storage backend...
.. include:: ../_includes/installing-and-provisioning-the-central-cloud.rest
where <X.Y.Z> are replaced with the correct values for your environment.

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

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

67
doc/source/dist_cloud/managing-subcloud-groups.rst Normal file
View File

@ -0,0 +1,67 @@
.. czv1600179275955
.. _managing-subcloud-groups:
======================
Manage Subcloud Groups
======================
Subclouds can be organized into subcloud groups. These subcloud groups can
control how subclouds are updated.
When a subcloud is created it is automatically added to the 'Default' subcloud
group, unless the group is specified. Subclouds can be associated with a
particular group when they are created, and that association can be changed to
a different subcloud group, if required. To create a subcloud group, see,
:ref:`Creating Subcloud Groups <creating-subcloud-groups>`.
For example, while creating a strategy, if several subclouds can be upgraded or
updated in parallel, they can be grouped together in a subcloud group that
supports parallel upgrades or updates. In this case, the
:command:`max\_parallel\_subclouds`, and :command:`subcloud\_apply\_type` are
**not** specified when the strategy is created, so that the settings in the
subcloud group are used.
Alternatively, if several subclouds should be upgraded or updated individually,
they can be grouped together in a subcloud group that supports serial updates.
In this case, the :command:`max\_parallel\_subclouds`,
and:command:`subcloud\_apply\_type` are **not** specified when creating the
strategy, and the subcloud group settings for
:command:`max\_parallel\_subclouds` \(not applicable\), and the
:command:`subcloud\_apply\_type` \(serial\) associated with that subcloud group
are used.
For more information on creating a strategy for orchestration upgrades, updates
or firmware updates, see:
.. _managing-subcloud-groups-ul-a3s-nqf-1nb:
- To create an upgrade orchestration strategy use the :command:`dcmanager
upgrade-strategy create` command.
.. xbooklink For more information see, :ref:`Distributed
Upgrade Orchestration Process Using the CLI
<distributed-upgrade-orchestration-process-using-the-cli>`.
- To create an update \(patch\) orchestration strategy use the
:command:`dcmanager patch-strategy create` command.
.. xbooklink For more information see,
:ref:`Creating an Update Strategy for Distributed Cloud Update Orchestration
<creating-an-update-strategy-for-distributed-cloud-update-orchestration>`.
- To create a firmware update orchestration strategy use the
:command:`dcmanager fw-update-strategy create` command.
.. xbooklink For more information
see, :ref:`Device Image Update Orchestration
<device-image-update-orchestration>`.
.. seealso::
:ref:`Creating Subcloud Groups <creating-subcloud-groups>`
:ref:`Orchestration Strategy Using Subcloud Groups <ochestration-strategy-using-subcloud-groups>`

170
doc/source/dist_cloud/managing-subclouds-using-the-cli.rst Normal file
View File

@ -0,0 +1,170 @@
.. rrh1558616429378
.. _managing-subclouds-using-the-cli:
==============================
Manage Subclouds Using the CLI
==============================
You can use the |CLI| to list subclouds, reconfigure subclouds if deployment
fails, delete subclouds, and monitor or change the managed status of subclouds.
.. rubric:: |proc|
.. _managing-subclouds-using-the-cli-steps-unordered-r4m-2w5-5cb:
- To list subclouds, use the :command:`subcloud list` command.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud list
+----+-----------+--------------+--------------------+-------------+
| id | name | management | availability | sync |
+----+-----------+--------------+--------------------+-------------+
| 1 | subcloud1 | managed | online | in-sync |
| 2 | subcloud2 | managed | online | in-sync |
| 3 | subcloud3 | managed | online | out-of-sync |
| 4 | subcloud4 | managed | offline | unknown |
+----+-----------+--------------+--------------------+-------------+
- To show information for a subcloud, use the :command:`subcloud show` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show <subcloud-name>
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show subcloud2
+-----------------------------+----------------------------+
| Field | Value |
+-----------------------------+----------------------------+
| id | 2 |
| name | subcloud2 |
| description | subcloud2 description |
| location | subcloud 2 location |
| software_version | 20.06 |
| management | managed |
| availability | online |
| deploy_status | complete |
| management_subnet | 192.168.101.0/24 |
| management_start_ip | 192.168.101.2 |
| management_end_ip | 192.168.101.50 |
| management_gateway_ip | 192.168.101.1 |
| systemcontroller_gateway_ip | 192.168.204.101 |
| created_at | 2020-03-05 21:43:46.525251 |
| updated_at | 2020-03-06 19:53:39.560771 |
| identity_sync_status | in-sync |
| patching_sync_status | in-sync |
| platform_sync_status | in-sync |
+-----------------------------+----------------------------+
- To show information about the oam-floating-ip field for a specific
subcloud, use the :command:`subcloud
show`<<subcloud-name\>>:command:`--detail` command.
For example,
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud show subcloud2 --detail
+-----------------------------+----------------------------+
| Field | Value |
+-----------------------------+----------------------------+
| id | 2 |
| name | subcloud2 |
| description | subcloud2 description |
| location | subcloud 2 location |
| software_version | 20.06 |
| management | managed |
| availability | online |
| deploy_status | complete |
| management_subnet | 192.168.101.0/24 |
| management_start_ip | 192.168.101.2 |
| management_end_ip | 192.168.101.50 |
| management_gateway_ip | 192.168.101.1 |
| systemcontroller_gateway_ip | 192.168.204.101 |
| created_at | 2020-03-05 21:43:46.525251 |
| updated_at | 2020-03-06 19:53:39.560771 |
| identity_sync_status | in-sync |
| patching_sync_status | in-sync |
| platform_sync_status | in-sync |
| oam_floating_ip | 10.10.10.12 |
+-----------------------------+----------------------------+
- To edit the settings for a subcloud, use the :command:`subcloud update`
command.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud update \
[–- description] <description> \
[– location] <location> \
<subcloud-name>
- To toggle a subcloud between **Unmanaged** and **Managed**, pass these
parameters to the :command:`subcloud` command.
For example:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud unmanage <subcloud-name>
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud manage <subcloud-name>
- To reconfigure a subcloud, if deployment fails, use the :command:`subcloud reconfig` command.
.. note::
You can enter the sysadmin password to avoid being prompted for the password.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud reconfig <subcloud-id/name> --deploy-config \
<<filepath>> --sysadmin-password <<password>>
where``--deploy-config`` must reference the deployment configuration file.
For more information, see either,
.. xbooklink |inst-doc|: :ref:`The
Deployment Manager <the-deployment-manager>` or |inst-doc|:
:ref:`Deployment Manager Examples <deployment-manager-examples>` for more
information on how to generate the file.
.. note::
The subcloud can be managed only if the deploy status is 'complete'.
Run the following command to manage the subcloud:
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud manage <subcloud-id/name>
- To delete a subcloud, use the :command:`subcloud delete` command.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud delete <subcloud-name>
.. caution::
You must reinstall a deleted subcloud before re-adding it.

45
doc/source/dist_cloud/monitoring-subclouds-using-horizon.rst Normal file
View File

@ -0,0 +1,45 @@
.. suc1558616448885
.. _monitoring-subclouds-using-horizon:
===============================
Monitor Subclouds Using Horizon
===============================
You can list subclouds, delete subclouds, and monitor or change the status of
subclouds from the System Controller.
.. rubric:: |proc|
- To list subclouds, select **Distributed Cloud Admin** \> **Cloud Overview**.
.. image:: figures/uhp1521894539008.png
You can perform full-text searches or filter by column using the search-bar
above the subcloud list.
.. image:: figures/pdn1591034100660.png
- To perform operations on a subcloud, use the **Actions** menu.
.. image:: figures/pvr1591032739503.png
.. caution::
If you delete a subcloud, then you must reinstall it before you can
re-add it.
The **Host Details** menu selection for a subcloud switches to the Horizon
Web interface for that subcloud. To switch back to the System Controller,
use the subcloud or region selection menu at the top left of the Horizon
window.
.. image:: figures/rpn1518108364837.png

27
doc/source/dist_cloud/ochestration-strategy-using-subcloud-groups.rst Normal file
View File

@ -0,0 +1,27 @@
.. afr1600186951848
.. _ochestration-strategy-using-subcloud-groups:
============================================
Orchestration Strategy Using Subcloud Groups
============================================
When an upgrade, update, or firmware update orchestration strategy is created,
the strategy ensures that the application of software upgrades, and updates are
done in the following order for the subclouds.
The order in which :command:`dcmanager subcloud-group list` displays the
subcloud groups, is the order they are processed by orchestration.
.. _ochestration-strategy-using-subcloud-groups-ol-hzg-q2v-ymb:
#. First, all subclouds in the default group.
#. All subclouds in the first, second, and third group, etc.
#. Subclouds from different groups will never be included in the same stage of
the strategy to ensure they are not upgraded, updated \(patched\) at the
same time.

25
doc/source/dist_cloud/overview-of-distributed-cloud.rst Normal file
View File

@ -0,0 +1,25 @@
.. eho1558617205547
.. _overview-of-distributed-cloud:
=============================
Overview of Distributed Cloud
=============================
|prod-long| |prod-dc| configuration supports an edge computing solution
by providing central management and orchestration for a geographically
distributed network of |prod| systems.
The |prod-dc| system is designed to meet the needs of edge-based data centers
in which NFC worker resources are localized for maximum responsiveness, while
management and control functions are centralized for efficient administration.
The system supports a scalable number of |prod| edge systems, centrally managed
and synchronized over L3 networks from a |prod| central region. Each edge
system is also highly scalable, from a single |prod| Simplex deployment to a
full Standard Cloud configuration with storage nodes.
The architecture features a synchronized distributed control plane for reduced
latency, with an autonomous control plane such that all subcloud local services
are operational even during loss of Northbound connectivity to the Central
Region.

17
doc/source/dist_cloud/regionone-and-systemcontroller-modes.rst Normal file
View File

@ -0,0 +1,17 @@
.. yqf1558616874924
.. _regionone-and-systemcontroller-modes:
====================================
RegionOne and SystemController Modes
====================================
You can operate the Central Cloud in **RegionOne** mode for local
configuration, or **SystemController** mode for |prod-dc| management.
To change the mode, select it in the Horizon Web interface top panel.
.. image:: figures/rpn1518108364837.png

62
doc/source/dist_cloud/shared-configurations.rst Normal file
View File

@ -0,0 +1,62 @@
.. chj1558616978053
.. _shared-configurations:
=====================
Shared Configurations
=====================
Shared configurations are |prod-long| system settings or services managed by
the System Controller and synchronized across all subclouds.
Synchronizations can be delayed slightly, depending on network traffic
conditions and the amount of information to be synchronized.
|prod| synchronizes configuration for selected attributes of system-wide
configurations \(see :ref:`Table 1
<shared-configurations-shared-sys-configs>`\) and synchronizes configuration
for resources of the Keystone Identity Service \(see :ref:`Table 2
<shared-configurations-shared-keystone-configs>`\).
.. _shared-configurations-shared-sys-configs:
.. table:: Table 1. Shared System Configurations
:widths: auto
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Shared Configuration | Remarks |
+=============================+==============================================================================================================================================================================================================================================================================================================================================================+
| 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. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Certificates | Subclouds use the digital certificates installed on the System Controller using the :command:`system certificate-install` command. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
.. _shared-configurations-shared-keystone-configs:
.. table:: Table 2. Shared Platform Keystone Resource Configurations
:widths: auto
+---------------+--------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Local Service | Shared Configuration | Remarks |
+===============+==========================+==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+
| Keystone | Users | To facilitate Single Sign-On across the entire |prod-dc|, and to enable centralized User Management, the Platform's Keystone's platform authentication identity resources are synced to the subclouds. If a new user, project, role or assignment, or changes to these resources are detected on the System Controller via Audit, they are automatically synced to the subclouds. If a subcloud is inaccessible or unmanaged at that time, then these resources and changes will be queued and synchronized once the subcloud becomes available. |
| | | |
| | Roles | The specific Keystone resources synchronized are: users, roles, projects, project roles, assignments, passwords and token revocation events. |
| | | |
| | Projects | |
| | | |
| | Project Role Assignments | |
| | | |
| | Passwords | |
| | | |
| | Token revocation events | |
+---------------+--------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

37
doc/source/dist_cloud/switching-to-a-subcloud-from-the-system-controller.rst Normal file
View File

@ -0,0 +1,37 @@
.. qig1558616383248
.. _switching-to-a-subcloud-from-the-system-controller:
===============================================
Switch to a Subcloud from the System Controller
===============================================
You can access the Horizon Web interface for individual subclouds from the System Controller.
.. rubric:: |context|
The System Controller page includes a menu for selecting subclouds or regions.
When you select a subcloud from this menu, the view changes to show the Horizon
interface for the subcloud. You can use this to provision and manage the
subcloud hosts and networks, just as you would for any |prod| system
.. rubric:: |proc|
.. _switching-to-a-subcloud-from-the-system-controller-steps-j55-m1t-hkb:
#. To switch to a subcloud, do one of the following.
- From the Horizon header, select a subcloud from the **Admin** menu.
.. image:: figures/rpn1518108364837.png
- From the Cloud Overview page, select **Alarm & Event Details** \> **Host Details** for the subcloud.
.. rubric:: |postreq|
To return to the System Controller page, use the subcloud selection menu.

41
doc/source/dist_cloud/synchronization-monitoring-and-control.rst Normal file
View File

@ -0,0 +1,41 @@
.. vhp1558616349331
.. _synchronization-monitoring-and-control:
======================================
Synchronization Monitoring and Control
======================================
Configuration changes made at the System Controller are synchronized
automatically across the |prod-dc|. You can monitor synchronization and enable
or disable it through the managed attribute of the subcloud.
Each subcloud is initially in the unmanaged state. Use the following command to
change the subcloud to the managed state and synchronize configuration data,
and to collect alarms from the subcloud.
.. code-block:: none
~(keystone_admin)]$ dcmanager subcloud manage <subcloud>
The subcloud is synchronized when it is first connected to the |prod-dc| and
set to managed. A backup audit and synchronization is run at regular intervals
\(every ten minutes\) for subclouds in the Managed state, synchronizing them to
the System Controller. You can view the synchronization status for individual
subclouds on the Cloud Overview page from **Distributed Cloud Admin** \>
**Cloud Overview**.
If a subcloud is not synchronized, it may be in an **Unmanaged** state. The
subcloud is synchronized immediately when it is changed to the **Managed**
state.
Configuration changes made from the System Controller, and i.e. by specifying
the --os-region-name option as **SystemController** are synchronized
immediately. For example, to add an |SNMP| trap destination and immediately
synchronize this configuration change to all subclouds in the **Managed**
state, use the following command:
.. code-block:: none
~(keystone_admin)]$ system --os-region-name SystemController snmp-trapdest-add -i 10.10.10.2 -c my-community

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

@ -0,0 +1,96 @@
.. qdu1595389242059
.. _updating-docker-registry-credentials-on-a-subcloud:
================================================
Update Docker Registry Credentials on a Subcloud
================================================
On a subcloud that uses the systemController's docker registry
(registry.central) as its install registry, one should use the
systemController's sysinv service credentials for accessing registry.central.
This makes access to registry.central independent of changes to the Distributed
Cloud's keystone admin user password.
Use the following procedure to update the install registry credentials on the
subcloud to the sysinv service credentials of the systemController.
.. rubric:: |proc|
.. _updating-docker-registry-credentials-on-a-subcloud-steps-ywx-wyt-kmb:
#. On the SystemController, get the password for the sysinv services.
.. code-block:: none
$ keyring get sysinv services
#. On each subcloud, run the following script to update the docker registry
credentials to sysinv:
.. code-block:: none
$ ./update_docker_registry_auth.sh sysinv <sysinv_password>
Where **./update\_docker\_registry\_auth.sh** script is:
.. code-block:: none
#!/bin/bash -e
USAGE="usage: ${0##*/} <username> <password>"
if [ "$#" -ne 2 ]
then
echo Missing arguments.
echo $USAGE
echo
exit
fi
NEW_CREDS="username:$1 password:$2"
echo
for REGISTRY in docker-registry quay-registry elastic-registry gcr-registry k8s-registry
do
echo -n "Updating" $REGISTRY "credentials ."
SECRET_UUID=`system service-parameter-list | fgrep $REGISTRY | fgrep auth-secret | awk '{print $10}'`
if [ -z "$SECRET_UUID" ]
then
echo "No $REGISTRY entry in service-parameters"
echo
continue
fi
SECRET_REF=`openstack secret list | fgrep ${SECRET_UUID} | awk '{print $2}'`
echo -n "."
SECRET_VALUE=`openstack secret get ${SECRET_REF} --payload -f value`
echo -n "."
openstack secret delete ${SECRET_REF} > /dev/null
echo -n "."
NEW_SECRET_VALUE=$NEW_CREDS
openstack secret store -n ${REGISTRY}-secret -p "${NEW_SECRET_VALUE}" > /dev/null
echo -n "."
NEW_SECRET_REF=`openstack secret list | fgrep ${REGISTRY}-secret | awk '{print $2}'`
NEW_SECRET_UUID=`echo "${NEW_SECRET_REF}" | awk -F/ '{print $6}'`
system service-parameter-modify docker $REGISTRY auth-secret="${NEW_SECRET_UUID}" > /dev/null
echo -n "."
echo " done."
echo -n "Validating $REGISTRY credentials updated to: "
SECRET_UUID=`system service-parameter-list | fgrep $REGISTRY | fgrep auth-secret | awk '{print $10}'`
if [ -z "$SECRET_UUID" ]
then
continue
fi
SECRET_REF=`openstack secret list | fgrep ${SECRET_UUID} | awk '{print $2}'`
SECRET_VALUE=`openstack secret get ${SECRET_REF} --payload -f value`
echo $SECRET_VALUE
echo
done

6
doc/source/fault-mgmt/index.rst
View File

@ -11,12 +11,6 @@ Fault Management
StarlingX Kubernetes
--------------------
An admin user can view |prod-long| fault management alarms and logs in order
to monitor and respond to fault conditions.
You can access active and historical alarms, and customer logs using the CLI,
GUI, REST APIs and |SNMP|.
.. toctree::
:maxdepth: 2

2
doc/source/fault-mgmt/kubernetes/cli-commands-for-dc-alarms-management.rst
View File

@ -6,7 +6,7 @@
CLI Commands for Distributed Cloud Alarm Management
===================================================
You can use the CLI to review alarm summaries for the Distributed Cloud.
You can use the CLI to review alarm summaries for the |prod-dc|.
.. _cli-commands-for-alarms-management-ul-ncv-m4y-fdb:

1
doc/source/fault-mgmt/kubernetes/index.rst
View File

@ -95,7 +95,6 @@ Distributed Cloud alarm management
.. toctree::
:maxdepth: 1
alarms-management-for-distributed-cloud
cli-commands-for-dc-alarms-management
******************************

9
doc/source/index.rst
View File

@ -183,8 +183,15 @@ Container integration
:maxdepth: 2
container_integration/kubernetes/index
-----------------
Distributed Cloud
-----------------
.. toctree::
:maxdepth: 2
dist_cloud/index
-------
Updates

2
doc/source/introduction/deploy_options.rst
View File

@ -31,6 +31,6 @@ Standard with Ironic
This configuration extends the standard configurations to add the OpenStack
Ironic service, which allows application workloads to run on bare metal servers.
Distributed Cloud
|prod-dc|
An upcoming feature for StarlingX that will allow one controller to control a
number of remote nodes.

2
doc/source/operations/dist_cloud_management.rst
View File

@ -2,7 +2,7 @@
Distributed Cloud Management
============================
This is a stub page for the topic: Distributed Cloud Management. You can help
This is a stub page for the topic: |prod-dc| Management. You can help
StarlingX by expanding the content.
See the story for additional information about what is needed:

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

@ -6,7 +6,7 @@
Centralized OIDC Authentication Setup for Distributed Cloud
===========================================================
In a Distributed Cloud configuration, you can configure |OIDC| authentication
In a |prod-dc| configuration, you can configure |OIDC| authentication
in a distributed or centralized setup.

85
doc/source/security/kubernetes/certificate_management_for_admin_rest_api_endpoints.rst
View File

@ -1,85 +0,0 @@
.. ygm1607361314876
.. _certificate_management_for_admin_REST_api_endpoints:
===================================================
Certificate Management for Admin REST API Endpoints
===================================================
All messaging between SystemControllers and Subclouds in the |prod-dc| system
uses the admin REST API service endpoints, which are all configured for secure
HTTPS.
|prod| supports automated HTTPS certificate renewal for |prod-dc| admin
endpoints.
.. _ygm1607361314876-section-lkn-ypk-xnb:
------------------------------------
Certificates on the SystemController
------------------------------------
In a |prod-dc| system, the HTTPS certificates for admin endpoints are managed
by |prod| internally.
.. note::
All renewal operations are automatic, and no user operation is required.
For admin endpoints, the SystemControllers in a |prod-dc| system manages the
following certificates:
.. _ygm1607361314876-ul-zdc-pmk-xnb:
**DC-AdminEp-Root-CA certificate**
This certificate expires in 1825 days \(approximately 5 years\). Renewal of
this certificate starts 30 days prior to expiry.
The Root CA certificate is renewed on the SystemController. When the
certificate is renewed, |prod| renews the intermediate CA certificates for
all subclouds.
**DC-AdminEp-Intermediate-CA certificate for 'each' subcloud**
This certificate expires in 365 days. Renewal of this certificate starts 30
days prior to expiry. This certificate is used for all unmanaged subclouds.
**DC-AdminEp-endpoint**
This certificate expires in 180 days. Renewal of this certificate starts 30
days prior to expiry.
.. _ygm1607361314876-section-qdd-xpk-xnb:
----------------------------
Certificates on the Subcloud
----------------------------
For admin endpoints, the subcloud controllers manage the following
certificates:
.. _ygm1607361314876-ul-x51-3qk-xnb:
**DC-AdminEp-Intermediate-CA certificate**
The intermediate |CA| certificate for a subcloud is renewed on the
SystemController. It is sent to the subcloud using a Rest API. Therefore,
a subcloud needs to be online to receive the renewed certificate.
If the subcloud is offline when the subcloud intermediate |CA|
certificate is renewed, the subcloud status **dc-cert** displays
"out-of-sync". Certificate renewal continues once the subcloud is online.
When renewal completes, the status changes to "in-sync". Subclouds start
admin endpoint certificate renewal once subcloud intermediate |CA|
certificate renewal is complete.
**DC-AdminEp certificate for the Subcloud**
This certificate expires in 180 days. Renewal of this certificate starts 30
days prior to expiry.
When the admin endpoint certificate is renewed, a new |TLS| certificate is
generated. The new |TLS| certificate is used to provide |TLS| termination.
The SystemController audits subcloud AdminEp certificates daily. It also audits
subcloud admin endpoints when a subcloud becomes online or managed. If the
subcloud admin endpoint is "out-of-sync", the SystemController initiates
intermediate CA certificate renewal, to force subcloud renewal of the admin
endpoint certificate.

11
doc/source/security/kubernetes/index.rst
View File

@ -309,15 +309,6 @@ Security Features
secure-https-external-connectivity
security-hardening-firewall-options
isolate-starlingx-internal-cloud-management-network
*********************************************************
Appendix: Certificate management for admin REST endpoints
*********************************************************
.. toctree::
:maxdepth: 1
certificate_management_for_admin_rest_api_endpoints
***************************************
Appendix: Locally creating certifciates
@ -327,4 +318,4 @@ Appendix: Locally creating certifciates
:maxdepth: 1
creating-certificates-locally-using-cert-manager-on-the-controller
creating-certificates-locally-using-openssl
creating-certificates-locally-using-openssl

1
doc/source/shared/abbrevs.txt
View File

@ -26,6 +26,7 @@
.. |CSK| replace:: :abbr:`CSK (Code Signing Key)`
.. |CSKs| replace:: :abbr:`CSKs (Code Signing Keys)`
.. |CVE| replace:: :abbr:`CVE (Common Vulnerabilities and Exposures)`
.. |DAD| replace:: :abbr:`DAD (Duplicate Address Detection)`
.. |DHCP| replace:: :abbr:`DHCP (Dynamic Host Configuration Protocol)`
.. |DMA| replace:: :abbr:`DMA (Direct Memory Access)`
.. |DNS| replace:: :abbr:`DNS (Domain Name System)`