diff --git a/doc/source/_includes/dm-doc-ref.rest b/doc/source/_includes/dm-doc-ref.rest new file mode 100644 index 000000000..e69de29bb diff --git a/doc/source/_includes/installing-a-subcloud-using-redfish-platform-management-service.rest b/doc/source/_includes/installing-a-subcloud-using-redfish-platform-management-service.rest new file mode 100644 index 000000000..617e3141e --- /dev/null +++ b/doc/source/_includes/installing-a-subcloud-using-redfish-platform-management-service.rest @@ -0,0 +1,5 @@ +.. begin-context +.. end-context + +.. begin-prereqs +.. end-prereqs \ No newline at end of file diff --git a/doc/source/_includes/installing-a-subcloud-without-redfish-platform-management-service.rest b/doc/source/_includes/installing-a-subcloud-without-redfish-platform-management-service.rest new file mode 100644 index 000000000..e69de29bb diff --git a/doc/source/_includes/installing-and-provisioning-a-subcloud.rest b/doc/source/_includes/installing-and-provisioning-a-subcloud.rest new file mode 100644 index 000000000..3db767bdd --- /dev/null +++ b/doc/source/_includes/installing-and-provisioning-a-subcloud.rest @@ -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 +`. + +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 +`. + +.. end-redfish-vms + +.. begin-shared-nic +.. end-shared-nic \ No newline at end of file diff --git a/doc/source/_includes/installing-and-provisioning-the-central-cloud.rest b/doc/source/_includes/installing-and-provisioning-the-central-cloud.rest new file mode 100644 index 000000000..faf3b0f20 --- /dev/null +++ b/doc/source/_includes/installing-and-provisioning-the-central-cloud.rest @@ -0,0 +1,16 @@ +.. code-block:: none + + system_mode: duplex + distributed_cloud_role: systemcontroller + + + management_start_address: .2 + management_end_address: .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 + ... \ No newline at end of file diff --git a/doc/source/_vendor/vendor_strings.txt b/doc/source/_vendor/vendor_strings.txt index 2c9c51518..6661d3830 100755 --- a/doc/source/_vendor/vendor_strings.txt +++ b/doc/source/_vendor/vendor_strings.txt @@ -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` diff --git a/doc/source/cli_ref/dcmanager.rst b/doc/source/cli_ref/dcmanager.rst index 297c6c259..e15ef58cf 100644 --- a/doc/source/cli_ref/dcmanager.rst +++ b/doc/source/cli_ref/dcmanager.rst @@ -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. diff --git a/doc/source/fault-mgmt/kubernetes/alarms-management-for-distributed-cloud.rst b/doc/source/dist_cloud/alarms-management-for-distributed-cloud.rst similarity index 83% rename from doc/source/fault-mgmt/kubernetes/alarms-management-for-distributed-cloud.rst rename to doc/source/dist_cloud/alarms-management-for-distributed-cloud.rst index 81c6cfc9d..6943f199d 100644 --- a/doc/source/fault-mgmt/kubernetes/alarms-management-for-distributed-cloud.rst +++ b/doc/source/dist_cloud/alarms-management-for-distributed-cloud.rst @@ -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. + diff --git a/doc/source/dist_cloud/certificate-management-for-admin-rest--api-endpoints.rst b/doc/source/dist_cloud/certificate-management-for-admin-rest--api-endpoints.rst new file mode 100644 index 000000000..8dad5e942 --- /dev/null +++ b/doc/source/dist_cloud/certificate-management-for-admin-rest--api-endpoints.rst @@ -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. + + + diff --git a/doc/source/dist_cloud/changing-the-admin-password-on-distributed-cloud.rst b/doc/source/dist_cloud/changing-the-admin-password-on-distributed-cloud.rst new file mode 100644 index 000000000..57905cfd3 --- /dev/null +++ b/doc/source/dist_cloud/changing-the-admin-password-on-distributed-cloud.rst @@ -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. + + diff --git a/doc/source/dist_cloud/cli-commands-for-alarms-management.rst b/doc/source/dist_cloud/cli-commands-for-alarms-management.rst new file mode 100644 index 000000000..5a9b1a337 --- /dev/null +++ b/doc/source/dist_cloud/cli-commands-for-alarms-management.rst @@ -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 | + | | | | | | + +----------+--------------------------------------------+-------------------+----------+-------------------+ + + + diff --git a/doc/source/dist_cloud/creating-subcloud-groups.rst b/doc/source/dist_cloud/creating-subcloud-groups.rst new file mode 100644 index 000000000..4233a1952 --- /dev/null +++ b/doc/source/dist_cloud/creating-subcloud-groups.rst @@ -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 <> + usage: dcmanager subcloud-group add [-h] [-f {json,shell,table,value,yaml}] + [-c COLUMN] [--max-width ] + [--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 + +------------------------+----------------------------+ + | 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 + `. + +- 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 ] + [--fit-width] [--print-empty] [--noindent] + [--prefix PREFIX] [--description DESCRIPTION] + [--location LOCATION] [--group GROUP] + [--install-values INSTALL_VALUES] + [--bmc-password BMC_PASSWORD] + subcloud + + diff --git a/doc/source/dist_cloud/distributed-cloud-architecture.rst b/doc/source/dist_cloud/distributed-cloud-architecture.rst new file mode 100644 index 000000000..cec69a885 --- /dev/null +++ b/doc/source/dist_cloud/distributed-cloud-architecture.rst @@ -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 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 + `. + + 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 `. + diff --git a/doc/source/dist_cloud/distributed-cloud-ports-reference.rst b/doc/source/dist_cloud/distributed-cloud-ports-reference.rst new file mode 100644 index 000000000..25cd03327 --- /dev/null +++ b/doc/source/dist_cloud/distributed-cloud-ports-reference.rst @@ -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 | | | + +----------+-------+----------------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+ + diff --git a/doc/source/dist_cloud/figures/bqu1525123082913.png b/doc/source/dist_cloud/figures/bqu1525123082913.png new file mode 100644 index 000000000..731e91da5 Binary files /dev/null and b/doc/source/dist_cloud/figures/bqu1525123082913.png differ diff --git a/doc/source/dist_cloud/figures/brk1525194697928.png b/doc/source/dist_cloud/figures/brk1525194697928.png new file mode 100644 index 000000000..91bad73fa Binary files /dev/null and b/doc/source/dist_cloud/figures/brk1525194697928.png differ diff --git a/doc/source/dist_cloud/figures/cah1525101473925.png b/doc/source/dist_cloud/figures/cah1525101473925.png new file mode 100644 index 000000000..976e40359 Binary files /dev/null and b/doc/source/dist_cloud/figures/cah1525101473925.png differ diff --git a/doc/source/dist_cloud/figures/jod1525122097274.png b/doc/source/dist_cloud/figures/jod1525122097274.png new file mode 100644 index 000000000..c4cc49659 Binary files /dev/null and b/doc/source/dist_cloud/figures/jod1525122097274.png differ diff --git a/doc/source/dist_cloud/figures/pdn1591034100660.png b/doc/source/dist_cloud/figures/pdn1591034100660.png new file mode 100644 index 000000000..7be706ee3 Binary files /dev/null and b/doc/source/dist_cloud/figures/pdn1591034100660.png differ diff --git a/doc/source/dist_cloud/figures/pvr1591032739503.png b/doc/source/dist_cloud/figures/pvr1591032739503.png new file mode 100644 index 000000000..e483f40ff Binary files /dev/null and b/doc/source/dist_cloud/figures/pvr1591032739503.png differ diff --git a/doc/source/dist_cloud/figures/qfq1525194569886.png b/doc/source/dist_cloud/figures/qfq1525194569886.png new file mode 100644 index 000000000..c2fd7e821 Binary files /dev/null and b/doc/source/dist_cloud/figures/qfq1525194569886.png differ diff --git a/doc/source/dist_cloud/figures/rpn1518108364837.png b/doc/source/dist_cloud/figures/rpn1518108364837.png new file mode 100644 index 000000000..0bb6bf9c9 Binary files /dev/null and b/doc/source/dist_cloud/figures/rpn1518108364837.png differ diff --git a/doc/source/dist_cloud/figures/tmj1525095688715.png b/doc/source/dist_cloud/figures/tmj1525095688715.png new file mode 100644 index 000000000..d30baf32d Binary files /dev/null and b/doc/source/dist_cloud/figures/tmj1525095688715.png differ diff --git a/doc/source/dist_cloud/figures/uhp1521894539008.png b/doc/source/dist_cloud/figures/uhp1521894539008.png new file mode 100644 index 000000000..f3db2a3e1 Binary files /dev/null and b/doc/source/dist_cloud/figures/uhp1521894539008.png differ diff --git a/doc/source/dist_cloud/figures/uzw1525102534768.png b/doc/source/dist_cloud/figures/uzw1525102534768.png new file mode 100644 index 000000000..8fbc2f088 Binary files /dev/null and b/doc/source/dist_cloud/figures/uzw1525102534768.png differ diff --git a/doc/source/dist_cloud/figures/vhy1525122582274.png b/doc/source/dist_cloud/figures/vhy1525122582274.png new file mode 100644 index 000000000..d33f38781 Binary files /dev/null and b/doc/source/dist_cloud/figures/vhy1525122582274.png differ diff --git a/doc/source/dist_cloud/figures/vwa1525194889921.png b/doc/source/dist_cloud/figures/vwa1525194889921.png new file mode 100644 index 000000000..50efe93e1 Binary files /dev/null and b/doc/source/dist_cloud/figures/vwa1525194889921.png differ diff --git a/doc/source/dist_cloud/figures/vzc1525194338519.png b/doc/source/dist_cloud/figures/vzc1525194338519.png new file mode 100644 index 000000000..b173bc8a2 Binary files /dev/null and b/doc/source/dist_cloud/figures/vzc1525194338519.png differ diff --git a/doc/source/dist_cloud/index.rst b/doc/source/dist_cloud/index.rst new file mode 100644 index 000000000..d76d57db7 --- /dev/null +++ b/doc/source/dist_cloud/index.rst @@ -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 diff --git a/doc/source/dist_cloud/installing-a-subcloud-using-redfish-platform-management-service.rst b/doc/source/dist_cloud/installing-a-subcloud-using-redfish-platform-management-service.rst new file mode 100644 index 000000000..d78ddb52e --- /dev/null +++ b/doc/source/dist_cloud/installing-a-subcloud-using-redfish-platform-management-service.rst @@ -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-.iso wind-river-cloud-platform-host-installer-.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 ` 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: + bootstrap_interface: # e.g. eno1 + bootstrap_address: # e.g.128.224.151.183 + bootstrap_address_prefix: # e.g. 23 + + # Board Management Controller + bmc_address: # e.g. 128.224.64.180 + 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: for # e.g. 128.224.150.1 (required) + network_address: # e.g. 128.224.144.0 + network_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: + + # 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: + type: docker + + Where 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: + 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 \ + --bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml \ + --sysadmin-password \ + --install-values /home/sysadmin/install-values.yaml \ + --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`` is used for subcloud + installation, and only required if the ``--install-values`` parameter is + specified. + + If the ``--bmc-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 `. + + 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 + `. + +#. 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/\_install\_.log. + + /var/log/dcmanager/\_bootstrap\_.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:". If + the secret payload is, "username: admin password:", see, + :ref:`Updating Docker Registry Credentials on a Subcloud + ` for more information. + +- For more information on bootstrapping and deploying |inst-doc|. diff --git a/doc/source/dist_cloud/installing-a-subcloud-without-redfish-platform-management-service.rst b/doc/source/dist_cloud/installing-a-subcloud-without-redfish-platform-management-service.rst new file mode 100644 index 000000000..9556df67a --- /dev/null +++ b/doc/source/dist_cloud/installing-a-subcloud-without-redfish-platform-management-service.rst @@ -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 `. + + .. 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 -o + [ -a ] [ -p param=value ] + [ -d ] [ -t ] + -i : Specify input ISO file + -o : Specify output ISO file + -a : Specify ks-addon.cfg file + + -p : 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 : + 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 : + 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: + type: docker + + + Where 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: + 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: IP.2: "**. + + 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 \ + --bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml \ + --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 + `. + +#. 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/\_bootstrap\_.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:". If the secret payload is, "username: admin + password:", see, :ref:`Updating Docker Registry Credentials on a + Subcloud ` for more + information. + +- For more information on bootstrapping and deploying see |inst-doc|. + + diff --git a/doc/source/dist_cloud/installing-and-provisioning-a-subcloud.rst b/doc/source/dist_cloud/installing-and-provisioning-a-subcloud.rst new file mode 100644 index 000000000..08e3d854d --- /dev/null +++ b/doc/source/dist_cloud/installing-and-provisioning-a-subcloud.rst @@ -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 diff --git a/doc/source/dist_cloud/installing-and-provisioning-the-central-cloud.rst b/doc/source/dist_cloud/installing-and-provisioning-the-central-cloud.rst new file mode 100644 index 000000000..3e31c6d2d --- /dev/null +++ b/doc/source/dist_cloud/installing-and-provisioning-the-central-cloud.rst @@ -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| + `. + +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 are replaced with the correct values for your environment. diff --git a/doc/source/dist_cloud/managing-ldap-linux-user-accounts-on-the-system-controller.rst b/doc/source/dist_cloud/managing-ldap-linux-user-accounts-on-the-system-controller.rst new file mode 100644 index 000000000..2d5d4a995 --- /dev/null +++ b/doc/source/dist_cloud/managing-ldap-linux-user-accounts-on-the-system-controller.rst @@ -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 +`. + diff --git a/doc/source/dist_cloud/managing-subcloud-groups.rst b/doc/source/dist_cloud/managing-subcloud-groups.rst new file mode 100644 index 000000000..70cedb4f1 --- /dev/null +++ b/doc/source/dist_cloud/managing-subcloud-groups.rst @@ -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 `. + +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 + `. + +- 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 + `. + +- 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 + `. + +.. seealso:: + + :ref:`Creating Subcloud Groups ` + + :ref:`Orchestration Strategy Using Subcloud Groups ` + + diff --git a/doc/source/dist_cloud/managing-subclouds-using-the-cli.rst b/doc/source/dist_cloud/managing-subclouds-using-the-cli.rst new file mode 100644 index 000000000..797fdbdec --- /dev/null +++ b/doc/source/dist_cloud/managing-subclouds-using-the-cli.rst @@ -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 + + + 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`<>: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] \ + [– location] \ + + + +- 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 + + + .. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud manage + + +- 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 --deploy-config \ + <> --sysadmin-password <> + + + where``--deploy-config`` must reference the deployment configuration file. + For more information, see either, + +.. xbooklink |inst-doc|: :ref:`The + Deployment Manager ` or |inst-doc|: + :ref:`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 + + +- To delete a subcloud, use the :command:`subcloud delete` command. + + .. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud delete + + + .. caution:: + + You must reinstall a deleted subcloud before re-adding it. + + diff --git a/doc/source/dist_cloud/monitoring-subclouds-using-horizon.rst b/doc/source/dist_cloud/monitoring-subclouds-using-horizon.rst new file mode 100644 index 000000000..59f995228 --- /dev/null +++ b/doc/source/dist_cloud/monitoring-subclouds-using-horizon.rst @@ -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 + + + + diff --git a/doc/source/dist_cloud/ochestration-strategy-using-subcloud-groups.rst b/doc/source/dist_cloud/ochestration-strategy-using-subcloud-groups.rst new file mode 100644 index 000000000..7e205e2ca --- /dev/null +++ b/doc/source/dist_cloud/ochestration-strategy-using-subcloud-groups.rst @@ -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. + + diff --git a/doc/source/dist_cloud/overview-of-distributed-cloud.rst b/doc/source/dist_cloud/overview-of-distributed-cloud.rst new file mode 100644 index 000000000..ab26f8fc9 --- /dev/null +++ b/doc/source/dist_cloud/overview-of-distributed-cloud.rst @@ -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. + diff --git a/doc/source/dist_cloud/regionone-and-systemcontroller-modes.rst b/doc/source/dist_cloud/regionone-and-systemcontroller-modes.rst new file mode 100644 index 000000000..3e5decb76 --- /dev/null +++ b/doc/source/dist_cloud/regionone-and-systemcontroller-modes.rst @@ -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 + + + diff --git a/doc/source/dist_cloud/shared-configurations.rst b/doc/source/dist_cloud/shared-configurations.rst new file mode 100644 index 000000000..639f6ffd8 --- /dev/null +++ b/doc/source/dist_cloud/shared-configurations.rst @@ -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 +`\) and synchronizes configuration +for resources of the Keystone Identity Service \(see :ref:`Table 2 +`\). + + +.. _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 | | + +---------------+--------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + diff --git a/doc/source/dist_cloud/switching-to-a-subcloud-from-the-system-controller.rst b/doc/source/dist_cloud/switching-to-a-subcloud-from-the-system-controller.rst new file mode 100644 index 000000000..c8ec21e7e --- /dev/null +++ b/doc/source/dist_cloud/switching-to-a-subcloud-from-the-system-controller.rst @@ -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. + diff --git a/doc/source/dist_cloud/synchronization-monitoring-and-control.rst b/doc/source/dist_cloud/synchronization-monitoring-and-control.rst new file mode 100644 index 000000000..a43840018 --- /dev/null +++ b/doc/source/dist_cloud/synchronization-monitoring-and-control.rst @@ -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 + +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 + diff --git a/doc/source/dist_cloud/updating-docker-registry-credentials-on-a-subcloud.rst b/doc/source/dist_cloud/updating-docker-registry-credentials-on-a-subcloud.rst new file mode 100644 index 000000000..ddf4a8d1d --- /dev/null +++ b/doc/source/dist_cloud/updating-docker-registry-credentials-on-a-subcloud.rst @@ -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 + + Where **./update\_docker\_registry\_auth.sh** script is: + + .. code-block:: none + + #!/bin/bash -e + + USAGE="usage: ${0##*/} " + + 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 + + diff --git a/doc/source/fault-mgmt/index.rst b/doc/source/fault-mgmt/index.rst index 870855fab..d0927c06a 100644 --- a/doc/source/fault-mgmt/index.rst +++ b/doc/source/fault-mgmt/index.rst @@ -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 diff --git a/doc/source/fault-mgmt/kubernetes/cli-commands-for-dc-alarms-management.rst b/doc/source/fault-mgmt/kubernetes/cli-commands-for-dc-alarms-management.rst index 08148dc8e..f30879545 100644 --- a/doc/source/fault-mgmt/kubernetes/cli-commands-for-dc-alarms-management.rst +++ b/doc/source/fault-mgmt/kubernetes/cli-commands-for-dc-alarms-management.rst @@ -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: diff --git a/doc/source/fault-mgmt/kubernetes/index.rst b/doc/source/fault-mgmt/kubernetes/index.rst index 4e33b2c5d..a6d770503 100644 --- a/doc/source/fault-mgmt/kubernetes/index.rst +++ b/doc/source/fault-mgmt/kubernetes/index.rst @@ -95,7 +95,6 @@ Distributed Cloud alarm management .. toctree:: :maxdepth: 1 - alarms-management-for-distributed-cloud cli-commands-for-dc-alarms-management ****************************** diff --git a/doc/source/index.rst b/doc/source/index.rst index 940e92e3f..942c3e9b4 100755 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -183,8 +183,15 @@ Container integration :maxdepth: 2 container_integration/kubernetes/index - +----------------- +Distributed Cloud +----------------- + +.. toctree:: + :maxdepth: 2 + + dist_cloud/index ------- Updates diff --git a/doc/source/introduction/deploy_options.rst b/doc/source/introduction/deploy_options.rst index 6040e4b20..651ca043e 100644 --- a/doc/source/introduction/deploy_options.rst +++ b/doc/source/introduction/deploy_options.rst @@ -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. diff --git a/doc/source/operations/dist_cloud_management.rst b/doc/source/operations/dist_cloud_management.rst index 2b82ef179..ccbb2c30a 100644 --- a/doc/source/operations/dist_cloud_management.rst +++ b/doc/source/operations/dist_cloud_management.rst @@ -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: diff --git a/doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst b/doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst index 38523ded3..48d241b1a 100644 --- a/doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst +++ b/doc/source/security/kubernetes/centralized-oidc-authentication-setup-for-distributed-cloud.rst @@ -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. diff --git a/doc/source/security/kubernetes/certificate_management_for_admin_rest_api_endpoints.rst b/doc/source/security/kubernetes/certificate_management_for_admin_rest_api_endpoints.rst deleted file mode 100644 index d0810638c..000000000 --- a/doc/source/security/kubernetes/certificate_management_for_admin_rest_api_endpoints.rst +++ /dev/null @@ -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. diff --git a/doc/source/security/kubernetes/index.rst b/doc/source/security/kubernetes/index.rst index 5b1a8914c..7344c9b76 100644 --- a/doc/source/security/kubernetes/index.rst +++ b/doc/source/security/kubernetes/index.rst @@ -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 \ No newline at end of file + creating-certificates-locally-using-openssl diff --git a/doc/source/shared/abbrevs.txt b/doc/source/shared/abbrevs.txt index 4609cc096..214d21464 100755 --- a/doc/source/shared/abbrevs.txt +++ b/doc/source/shared/abbrevs.txt @@ -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)`