starlingx/docs
Code Issues Proposed changes

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

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

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

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

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

@@ -19,9 +19,9 @@ endpoints.
.. certificate-management-for-admin-rest--api-endpoints-section-lkn-ypk-xnb: .. certificate-management-for-admin-rest--api-endpoints-section-lkn-ypk-xnb:
------------------------------------ -------------------------------------
Certificates on the System Controller Certificates on the System Controller
------------------------------------ -------------------------------------
In a |prod-dc| system, the HTTPS certificates for admin endpoints are In a |prod-dc| system, the HTTPS certificates for admin endpoints are
managed by |prod| internally. managed by |prod| internally.

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

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

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

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

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

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

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

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

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

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

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

@@ -30,11 +30,9 @@ for resources of the Keystone Identity Service \(see :ref:`Table 2
+=============================+==============================================================================================================================================================================================================================================================================================================================================================+ +=============================+==============================================================================================================================================================================================================================================================================================================================================================+
| DNS IP addresses | Subclouds use the DNS servers specified at the System Controller. | | DNS IP addresses | Subclouds use the DNS servers specified at the System Controller. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| SNMP community and trapdest | Subclouds use the SNMP alarm trap and destination settings specified at the System Controller, for example using the :command:`system snmp-comm-add`, :command:`system snmp-comm-delete`, and :command:`system snmp-trapdest-add` commands. A subcloud may use additional local settings; if present, these are not synchronized with the System Controller. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| **sysadmin** Password | The **sysadmin** password may take up to 10 minutes to sync with the controller. The **sysadmin** password is not modified via the :command:`system` command. It is modified using the regular Linux :command:`passwd` command. | | **sysadmin** Password | The **sysadmin** password may take up to 10 minutes to sync with the controller. The **sysadmin** password is not modified via the :command:`system` command. It is modified using the regular Linux :command:`passwd` command. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Certificates | Subclouds use the digital certificates installed on the System Controller using the :command:`system certificate-install` command. | | Certificates | Subclouds use the Trusted |CA| certificates installed on the System Controller using the :command:`system certificate-install -m ssl_ca` command. |
+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -65,6 +65,10 @@ See :ref:`Upgrading All-in-One Duplex / Standard
controller node before doing the upgrade orchestration described below to controller node before doing the upgrade orchestration described below to
upgrade the remaining nodes of the |prod|. upgrade the remaining nodes of the |prod|.
- The subclouds must use the Redfish platform management service if it is an All-in-one Simplex subcloud.
- Duplex \(AIODX/Standard\) upgrades are supported, and they do not require remote install via Redfish.
.. rubric:: |proc| .. rubric:: |proc|
.. _performing-an-orchestrated-upgrade-using-the-cli-steps-e45-kh5-sy: .. _performing-an-orchestrated-upgrade-using-the-cli-steps-e45-kh5-sy:

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

@@ -24,7 +24,7 @@ You can perform a partially-Orchestrated Upgrade of a |prod| system using the CL
During an orchestrated upgrade, the following alarms are ignored even when During an orchestrated upgrade, the following alarms are ignored even when
strict restrictions are selected: strict restrictions are selected:
- 750.006, Automatic application re-apply is pending - 750.006, Generic alarm for any platform-managed applications as they are auto-applied
- 900.005, Upgrade in progress - 900.005, Upgrade in progress