From 4dd4fa7463c9f281f27f60725774be100c34d75a Mon Sep 17 00:00:00 2001 From: egoncalv Date: Fri, 21 May 2021 17:03:32 -0300 Subject: [PATCH] Editorial updates - Admin Tasks, User tasks, and Updates and Upgrades Guides. Acted on Greg's comments Patch 1: Acted on Greg's comments and added the missing files. Patch 2: Solved merge conflicts Signed-off-by: egoncalv Change-Id: I70c5d3b9c3927320f977b62878ee60ab9956fc91 --- ...dating-the-docker-registry-certificate.rst | 6 +- ...rials-authentication-and-authorization.rst | 6 +- .../setting-up-a-public-repository.rst | 6 +- ...e-of-the-cert-manager-acmesolver-image.rst | 2 +- ...onfigure-firmware-update-orchestration.rst | 164 +++++++++++ ...-operations-requiring-manual-migration.rst | 48 ++++ ...are-update-orchestration-using-the-cli.rst | 257 ++++++++++++++++++ ...firmware-update-orchestration-failures.rst | 108 ++++++++ doc/source/updates/kubernetes/index.rst | 15 +- .../manual-kubernetes-components-upgrade.rst | 6 +- ...rview-of-firmware-update-orchestration.rst | 55 ++++ ...-firmware-update-orchestration-process.rst | 106 ++++++++ ...ubernetes-update-orchestration-process.rst | 2 +- doc/source/usertasks/index.rs1 | 0 doc/source/usertasks/kubernetes/index.rst | 5 +- 15 files changed, 768 insertions(+), 18 deletions(-) create mode 100644 doc/source/updates/kubernetes/configure-firmware-update-orchestration.rst create mode 100644 doc/source/updates/kubernetes/firmware-update-operations-requiring-manual-migration.rst create mode 100644 doc/source/updates/kubernetes/firmware-update-orchestration-using-the-cli.rst create mode 100644 doc/source/updates/kubernetes/handle-firmware-update-orchestration-failures.rst create mode 100644 doc/source/updates/kubernetes/overview-of-firmware-update-orchestration.rst create mode 100644 doc/source/updates/kubernetes/the-firmware-update-orchestration-process.rst create mode 100644 doc/source/usertasks/index.rs1 diff --git a/doc/source/admintasks/installing-updating-the-docker-registry-certificate.rst b/doc/source/admintasks/installing-updating-the-docker-registry-certificate.rst index d63b41895..e23cb8ddb 100644 --- a/doc/source/admintasks/installing-updating-the-docker-registry-certificate.rst +++ b/doc/source/admintasks/installing-updating-the-docker-registry-certificate.rst @@ -2,9 +2,9 @@ .. idr1582032622279 .. _installing-updating-the-docker-registry-certificate: -============================================== -Install/Update the Docker Registry Certificate -============================================== +==================================================== +Install/Update the Local Docker Registry Certificate +==================================================== The local Docker registry provides secure HTTPS access using the registry API. diff --git a/doc/source/admintasks/kubernetes-admin-tutorials-authentication-and-authorization.rst b/doc/source/admintasks/kubernetes-admin-tutorials-authentication-and-authorization.rst index f6d8e0010..6645bcb92 100644 --- a/doc/source/admintasks/kubernetes-admin-tutorials-authentication-and-authorization.rst +++ b/doc/source/admintasks/kubernetes-admin-tutorials-authentication-and-authorization.rst @@ -2,9 +2,9 @@ .. khe1563458421728 .. _kubernetes-admin-tutorials-authentication-and-authorization: -================================ -Authentication and Authorization -================================ +======================================================= + Local Docker Registry Authentication and Authorization +======================================================= Authentication is enabled for the local Docker registry. When logging in, users are authenticated using their platform keystone credentials. diff --git a/doc/source/admintasks/setting-up-a-public-repository.rst b/doc/source/admintasks/setting-up-a-public-repository.rst index 60e17fff9..70b2046b9 100644 --- a/doc/source/admintasks/setting-up-a-public-repository.rst +++ b/doc/source/admintasks/setting-up-a-public-repository.rst @@ -2,9 +2,9 @@ .. qay1588350945997 .. _setting-up-a-public-repository: -========================== -Set up a Public Repository -========================== +=================================================== +Set up a Public Repository in Local Docker Registry +=================================================== There will likely be scenarios where you need to make images publicly available to all users. diff --git a/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst b/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst index 372310bb6..47557809e 100644 --- a/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst +++ b/doc/source/security/kubernetes/enable-public-use-of-the-cert-manager-acmesolver-image.rst @@ -23,7 +23,7 @@ However, this repository within registry.local is secured such that only The registry.local:9001:/quay.io/jetstack/cert-manager-acmesolver: image needs to be copied by **admin** into a public repository, registry.local:9001:/public. If you have not yet set up a public -repository, see |admintasks-doc|: :ref:`Setting up a Public Repository +repository, see |admintasks-doc|: :ref:`Set up a Public Repository in Local Docker Registry `. .. rubric:: |proc| diff --git a/doc/source/updates/kubernetes/configure-firmware-update-orchestration.rst b/doc/source/updates/kubernetes/configure-firmware-update-orchestration.rst new file mode 100644 index 000000000..15293cca2 --- /dev/null +++ b/doc/source/updates/kubernetes/configure-firmware-update-orchestration.rst @@ -0,0 +1,164 @@ + +.. noc1590162360081 +.. _configure-firmware-update-orchestration: + +======================================= +Configure Firmware Update Orchestration +======================================= + +You can configure *Firmware Update Orchestration Strategy* using the +**sw-manager** |CLI|. + +.. note:: + Management-affecting alarms cannot be ignored using relaxed alarm rules + during an orchestrated firmware update operation. For a list of + management-affecting alarms, see |prod| Fault Management: + :ref:`Alarm Messages <100-series-alarm-messages>`. To display + management-affecting active alarms, use the following command: + +.. code-block:: none + + ~(keystone_admin)$ fm alarm-list --mgmt_affecting + +During an orchestrated firmware update operation, the following alarms are +ignored even when the default strict restrictions are selected: + +.. _noc1590162360081-ul-vhg-jxs-tlb: + +- 200.001: Maintenance host lock alarm + +- 280.002: Subcloud resource out-of-sync + +- 700.004: VM stopped + +- 900.301: Firmware update auto apply in progress + +.. rubric:: |prereq| + +.. _noc1590162360081-ul-ls2-pxs-tlb: + +- Hosts that need to be updated must be in the **unlocked-enabled** state. + +- The firmware update image must be in the **applied** state. For more + information, see :ref:`Managing Software Updates `. + +.. rubric:: |proc| + +#. Create the strategy. + + The *Firmware Update Orchestration Strategy* :command:`create` command + creates a series of stages with steps that apply the firmware update to the + hardware. + + Firmware update requires a reboot. Therefore, the created strategy includes + steps that automatically lock and unlock the host to bring the new image + function into service. + + .. code-block:: none + + ~(keystone_admin)$ sw-manager fw-update-strategy create + Strategy Firmware Update Strategy: + strategy-uuid: 3e43c018-9c75-4ba8-a276-472c3bcbb268 + controller-apply-type: ignore + storage-apply-type: ignore + worker-apply-type: serial + default-instance-action: stop-start + alarm-restrictions: strict + current-phase: build + current-phase-completion: 0% + state: building + inprogress: true + +#. Optional: Display the strategy in summary, if required. The firmware update + strategy :command:`show` command displays the strategy in a summary. + + .. code-block:: none + + ~(keystone_admin)$ sw-manager fw-update-strategy show + Strategy Firmware Update Strategy: + strategy-uuid: 3e43c018-9c75-4ba8-a276-472c3bcbb268 + controller-apply-type: ignore + storage-apply-type: ignore + worker-apply-type: serial + default-instance-action: stop-start + alarm-restrictions: strict + current-phase: build + current-phase-completion: 100% + state: ready-to-apply + build-result: success + + The strategy steps and stages are displayed using the **--details** option. + +#. Apply the strategy. + + *Firmware Update Orchestration Strategy* :command:`apply` command executes + the strategy stages and steps consecutively until the firmware update on + all the hosts in the strategy is complete. + + + - Use the **-stage-id** option to specify a specific stage to apply; one + at a time. + + .. note:: + When applying a single stage, only the next stage will be applied; + you cannot skip stages. + + + .. code-block:: none + + ~(keystone_admin)$sw-manager fw-update-strategy apply + Strategy Firmware Update Strategy: + strategy-uuid: 3e43c018-9c75-4ba8-a276-472c3bcbb268 + controller-apply-type: ignore + storage-apply-type: ignore + worker-apply-type: serial + default-instance-action: stop-start + alarm-restrictions: strict + current-phase: apply + current-phase-completion: 0% + state: applying + inprogress: true + + + - Use the :command:`show` command to monitor firmware update state and + percentage completion. + + .. code-block:: none + + ~(keystone_admin)$sw-manager fw-update-strategy show + Strategy Firmware Update Strategy: + strategy-uuid: 3e43c018-9c75-4ba8-a276-472c3bcbb268 + controller-apply-type: ignore + storage-apply-type: ignore + worker-apply-type: serial + default-instance-action: stop-start + alarm-restrictions: strict + current-phase: apply + current-phase-completion: 50% + state: applying + inprogress: true + +#. Optional: Abort the strategy, if required. This is only used to stop, and + abort the entire strategy. + + The firmware update strategy :command:`abort` command can be used to abort + the firmware update strategy after the current step of the currently + applying stage is completed. + +#. Delete the strategy. + + .. note:: + After the *Firmware Update Orchestration Strategy* has been applied + \(or aborted\) it must be deleted before another firmware update + strategy can be created. If a firmware update strategy application + fails, you must address the issue that caused the failure, then + delete and re-create the strategy before attempting to apply it + again. + + .. code-block:: none + + ~(keystone_admin)$sw-manager fw-update-strategy delete + Strategy deleted. + +For more information see :ref:`Firmware Update Orchestration Using the CLI +`. diff --git a/doc/source/updates/kubernetes/firmware-update-operations-requiring-manual-migration.rst b/doc/source/updates/kubernetes/firmware-update-operations-requiring-manual-migration.rst new file mode 100644 index 000000000..867b95a12 --- /dev/null +++ b/doc/source/updates/kubernetes/firmware-update-operations-requiring-manual-migration.rst @@ -0,0 +1,48 @@ + +.. rbp1590431075472 +.. _firmware-update-operations-requiring-manual-migration: + +===================================================== +Firmware Update Operations Requiring Manual Migration +===================================================== + +On systems with the |prefix|-openstack application there may be some instances +that cannot be migrated automatically by orchestration. In these cases the +instance migration must be managed manually. + +Do the following to manage the instance re-location manually: + + +.. _rbp1590431075472-ul-mgr-kvs-tlb: + +- Manually firmware update at least one openstack-compute worker host. This + assumes that at least one openstack-compute worker host does not have any + instances, or has instances that can be migrated. For more information on + manually updating a host, see the :ref:`Display Worker Host Information + `. + +- If the migration is prevented by limitations in the VNF or virtual + application, perform the following: + + + - Create new instances on an already updated openstack-compute worker host. + + - Manually migrate the data from the old instances to the new instances. + + .. note:: + This is specific to your environment and depends on the virtual + application running in the instance. + + - Terminate the old instances. + +- If the migration is prevented by the size of the instances local disks: + + - For each openstack-compute worker host that has instances that cannot + be migrated, manually move the instances using the CLI. For more + information, see :ref:`Firmware Update Orchestration Using the CLI + `. + +Once all openstack-compute worker hosts containing instances that cannot be +migrated have been firmware updated, firmware update orchestration can then be +used to update the remaining worker hosts. + diff --git a/doc/source/updates/kubernetes/firmware-update-orchestration-using-the-cli.rst b/doc/source/updates/kubernetes/firmware-update-orchestration-using-the-cli.rst new file mode 100644 index 000000000..c6986ca0a --- /dev/null +++ b/doc/source/updates/kubernetes/firmware-update-orchestration-using-the-cli.rst @@ -0,0 +1,257 @@ + +.. tsr1590164474201 +.. _firmware-update-orchestration-using-the-cli: + +=========================================== +Firmware Update Orchestration Using the CLI +=========================================== + +You can configure the *Firmware Update Orchestration Strategy* using the +**sw-manager** |CLI|. + +--------------- +About this task +--------------- + +.. note:: + You require administrator privileges to use **sw-manager**. You must log in + to the active controller as **user sysadmin** and source the script by + using the command, source /etc/platform/openrc to obtain administrator + privileges. Do not use sudo. + +.. note:: + Management-affecting alarms cannot be ignored at the indicated severity + level or higher by using relaxed alarm rules during an orchestrated + firmware update operation. For a list of management-affecting alarms, see + |prod| Fault Management: :ref:`Alarm Messages + <100-series-alarm-messages>`. To display management-affecting active + alarms, use the following command: + +.. code-block:: none + + ~(keystone_admin)$ fm alarm-list --mgmt_affecting + +During an orchestrated firmware update operation, the following alarms are +ignored even when strict restrictions are selected: + +.. _tsr1590164474201-ul-hq4-nkt-tlb: + +- 200.001: Maintenance host lock alarm + +- 280.002: Subcloud resource out-of-sync + +- 700.004: VM stopped + +- 900.301: Firmware update auto apply in progress + +You can use 'help' for the overall commands and also for each sub-command. For +example: + +.. code-block:: none + + ~(keystone_admin)$ sw-manager fw-update-strategy –help + usage: sw-manager fw-update-strategy [-h] ... + optional arguments: + -h, --help show this help message and exit + Firmware Update Commands: + create Create a strategy + delete Delete a strategy + apply Apply a strategy + abort Abort a strategy + show Show a strategy + +.. _tsr1590164474201-section-edz-4p5-tlb: + +--------------------------------------------- +Firmware update orchestration strategy create +--------------------------------------------- + +The :command:`create` strategy subcommand with no options specified creates a +firmware update strategy with default settings. A firmware update strategy can +be created with override worker apply type concurrency with a max host +parallelism, instance action, and alarm restrictions. + +**--controller-apply-type, and --storage-apply-type** + +These options cannot be changed from '**ignore**' because firmware update +is only supported for worker hosts. + +.. note:: + Firmware update is currently only supported for hosts with worker + function. Any attempt to modify the controller or storage apply type is + rejected. + +**--worker-apply-type** + +This option specifies the host concurrency of the firmware update strategy: + +- serial \(default\): worker hosts will be patched one at a time + +- parallel: worker hosts will be updated in parallel + + - At most, **parallel** will be updated at the same time + + - At most, half of the hosts in a host aggregate will be updated at the + same time + +- ignore: worker hosts will not be updated; strategy create will fail + +Worker hosts with no instances are updated before worker hosts with instances. + +**--max-parallel-worker-hosts** + +This option applies to the parallel worker apply type selection to specify +the maximum worker hosts to update in parallel \(minimum: 2, maximum: 10\). + +**–instance-action** + +This option only has significance when the stx-openstack application is +loaded and there are instances running on worker hosts. It specifies how +the strategy deals with worker host instances over the strategy execution. + +**stop-start \(default\)** + +Instances will be stopped before the host lock operation following the +update and then started again following the host unlock. + +.. warning:: + Using the **stop-start** option will result in an outage for each + instance, as it is stopped while the worker host is locked/unlocked. In + order to ensure this does not impact service, instances MUST be grouped + into anti-affinity \(or anti-affinity best effort\) server groups, + which will ensure that only a single instance in each server group is + stopped at a time. + +**migrate** + +Instances will be migrated off a host before it is patched \(this applies +to reboot patching only\). + +**--alarm-restrictions** + +This option sets how the how the firmware update orchestration behaves when +alarms are present. + +To display management-affecting active alarms, use the following command: + +.. code-block:: none + + ~(keystone_admin)$ fm alarm-list --mgmt_affecting + +**strict \(default\)** + +The default strict option will result in patch orchestration failing if +there are any alarms present in the system \(except for a small list of +alarms\). + +**relaxed** + +This option allows orchestration to proceed if alarms are present, as long +as none of these alarms are management affecting. + +.. code-block:: none + + ~(keystone_admin)]$ sw-manager fw-update-strategy create --help + usage:sw-manager fw-update-strategy create [-h] + [--controller-apply-type {ignore}] + [--storage-apply-type {ignore}] + [--worker-apply-type + {serial,parallel,ignore}] + [--max-parallel-worker-hosts + {2,3,4,5,6,7,8,9,10}] + [--instance-action {migrate,stop-start}] + [--alarm-restrictions {strict,relaxed}] + + optional arguments: + -h, --help show this help message and exit + --controller-apply-type {ignore} + defaults to ignore + --storage-apply-type {ignore} + defaults to ignore + --worker-apply-type {serial,parallel,ignore} + defaults to serial + --max-parallel-worker-hosts {2,3,4,5,6,7,8,9,10} + maximum worker hosts to update in parallel + --instance-action {migrate,stop-start} + defaults to stop-start + --alarm-restrictions {strict,relaxed} + defaults to strict + + +.. _tsr1590164474201-section-l3x-wr5-tlb: + +------------------------------------------- +Firmware update orchestration strategy show +------------------------------------------- + +The :command:`show` strategy subcommand displays a summary of the current state +of the strategy. A complete view of the strategy can be shown using the +**--details** option. + +.. code-block:: none + + ~(keystone_admin)]$ sw-manager fw-update-strategy show --help + usage: sw-manager fw-update-strategy show [-h] [--details] + + optional arguments: + -h, --help show this help message and exit + --details show strategy details + +.. _tsr1590164474201-section-ecp-2s5-tlb: + +-------------------------------------------- +Firmware update orchestration strategy apply +-------------------------------------------- + +The :command:`apply` strategy subcommand with no options executes the firmware +update strategy from current state to the end. The apply strategy operation can +be called with the **stage-id** option to execute the next stage of the +strategy. The **stage-id** option cannot be used to execute the strategy out of +order. + +.. code-block:: none + + ~(keystone_admin)]$ sw-manager fw-update-strategy apply --help + usage: sw-manager fw-update-strategy apply [-h] [--stage-id STAGE_ID] + + optional arguments: + -h, --help show this help message and exit + --stage-id STAGE_ID stage identifier to apply + +.. _tsr1590164474201-section-lmp-ks5-tlb: + +-------------------------------------------- +Firmware update orchestration strategy abort +-------------------------------------------- + +The **abort** strategy subcommand with no options sets the strategy to abort +after the current applying stage is complete. The abort strategy operation can +be called with the **stage-id** option to specify that the strategy abort +before executing the next stage of the strategy. The **stage-id** option cannot +be used to execute the strategy out of order. + +.. code-block:: none + + ~(keystone_admin)]$ sw-manager fw-update-strategy abort --help + usage: sw-manager fw-update-strategy abort [-h] [--stage-id STAGE_ID] + + optional arguments: + -h, --help show this help message and exit + --stage-id STAGE_ID stage identifier to abort + +.. _tsr1590164474201-section-z5b-qs5-tlb: + +--------------------------------------------- +Firmware update orchestration strategy delete +--------------------------------------------- + +The **delete** strategy subcommand with no options deletes a strategy. + +.. code-block:: none + + ~(keystone_admin)]$sw-manager fw-update-strategy delete --help + usage: sw-manager fw-update-strategy delete [-h] + + optional arguments: + -h, --help show this help message and exit + diff --git a/doc/source/updates/kubernetes/handle-firmware-update-orchestration-failures.rst b/doc/source/updates/kubernetes/handle-firmware-update-orchestration-failures.rst new file mode 100644 index 000000000..26337a3e4 --- /dev/null +++ b/doc/source/updates/kubernetes/handle-firmware-update-orchestration-failures.rst @@ -0,0 +1,108 @@ + +.. jkf159018462371 +.. _handle-firmware-update-orchestration-failures: + +============================================= +Handle Firmware Update Orchestration Failures +============================================= + +The creation or application of a strategy could fail for any of the listed +reasons described in this section. Follow the suggested actions in each case to +resolve the issue. + +------------------------- +Strategy creation failure +------------------------- + +.. _jkf1590184623714-ul-fvs-vnq-5lb: + +- **Reason**: build failed with no reason + + - **Action**: + + - verify that the **--worker-apply-type** was not set to '**ignore**' + + - check recent logs added to /var/log/nfv-vim.log + +- **Reason**: alarms from platform are present + + - **Action**: + + - query for management affecting alarms and take actions to clear them + + .. code-block:: none + + ~(keystone_admin)$ fm alarm-list --mgmt_affecting + + - if there are no management affecting alarms present take actions to + clear other reported alarms or try creating the strategy with the + '**relaxed**' alarms restrictions option **--alarm-restrictions + relaxed** + +- **Reason**: no firmware update required + + - **Action**: + + - verify that the firmware device image has been applied for the + worker hosts that require updating + + .. note:: + If the strategy create failed. After resolving the strategy + create failure you must delete the failed strategy before + trying to create another strategy. + +---------------------- +Strategy apply failure +---------------------- + +.. _jkf1590184623714-ul-rdf-4pq-5lb: + +- **Reason**: alarms from platform are present + + - **Action**: suggests that an alarm has been raised since the creation + of the strategy. Address the cause of the new alarm, delete the strategy + and try creating and applying a new strategy + +- **Reason**: unable to migrate instances + + - **Action**: See :ref:`Firmware Update Operations Requiring Manual + Migration ` for + steps to resolve migration issues. + +- **Reason**: firmware update failed. Suggests that the firmware update for + the specified host has failed + + - **Action**: For more information, see |prod| Node Management: + :ref:`Display Worker Host Information ` + +- **Reason**: lock host failed + + - **Action**: + + - investigate the /var/log/sysinv.log, and /var/log/nfv-vim.log files + + - address the underlying issue + + - manually lock and unlock the host + + - try recreating and re-applying the firmware update strategy to + automatically finish the update process + +- **Reason**: unlock host failed + + - **Action**: + + - investigate /var/log/mtcAgent.log file for cause logs files + + - address the underlying issue + + - manually lock and unlock the host to recover + + - try recreating and re-applying the firmware update strategy to + automatically finish the update process + +.. note:: + If the strategy :command:`apply` fails, you must resolve the + strategy:command:`apply` failure, and delete the failed strategy before + trying to create and apply another strategy. + diff --git a/doc/source/updates/kubernetes/index.rst b/doc/source/updates/kubernetes/index.rst index 294d8951a..51cc39f2e 100644 --- a/doc/source/updates/kubernetes/index.rst +++ b/doc/source/updates/kubernetes/index.rst @@ -46,6 +46,20 @@ Orchestrated Software Update configuring-update-orchestration update-orchestration-cli +---------------------------------------- +N3000 FPGA Firmware Update Orchestration +---------------------------------------- + +.. toctree:: + :maxdepth: 1 + + overview-of-firmware-update-orchestration + the-firmware-update-orchestration-process + firmware-update-operations-requiring-manual-migration + configure-firmware-update-orchestration + firmware-update-orchestration-using-the-cli + handle-firmware-update-orchestration-failures + --------------------------------- Manual Kubernetes Version Upgrade --------------------------------- @@ -56,7 +70,6 @@ Manual Kubernetes Version Upgrade manual-kubernetes-components-upgrade - ---------------------------------------------- Kubernetes Version Upgrade Cloud Orchestration ---------------------------------------------- diff --git a/doc/source/updates/kubernetes/manual-kubernetes-components-upgrade.rst b/doc/source/updates/kubernetes/manual-kubernetes-components-upgrade.rst index ad21c5969..974035f54 100644 --- a/doc/source/updates/kubernetes/manual-kubernetes-components-upgrade.rst +++ b/doc/source/updates/kubernetes/manual-kubernetes-components-upgrade.rst @@ -2,9 +2,9 @@ .. bfd1591638638205 .. _manual-kubernetes-components-upgrade: -=========================== -Kubernetes Version Upgrade -=========================== +================================= +Manual Kubernetes Version Upgrade +================================= You can upgrade the Kubernetes version on a running system from one supported version to another. diff --git a/doc/source/updates/kubernetes/overview-of-firmware-update-orchestration.rst b/doc/source/updates/kubernetes/overview-of-firmware-update-orchestration.rst new file mode 100644 index 000000000..2e7efbda1 --- /dev/null +++ b/doc/source/updates/kubernetes/overview-of-firmware-update-orchestration.rst @@ -0,0 +1,55 @@ + +.. xkr159015711692 +.. _overview-of-firmware-update-orchestration: + +======== +Overview +======== + +Firmware update orchestration allows the firmware on the hosts of an entire +|prod-long| system to be updated with a single operation. + +You can configure and run firmware update orchestration using the |CLI|, or the +stx-nfv VIM REST API. + +.. note:: + Firmware update is currently not supported on the Horizon Web interface. + Only host device |FPGA| firmware update is currently supported. + +------------------------------------------ +Firmware update orchestration requirements +------------------------------------------ + +Firmware update orchestration can only be done on a system that meets the +following conditions: + +- The system is clear of alarms \(with the exception of alarms for locked + hosts, stopped instances, and firmware updates in progress\). + + .. note:: + When configuring firmware update orchestration, you have the option to + ignore alarms that are not management-affecting severity. For more + information, see :ref:`Kubernetes Version Upgrade Cloud Orchestration + `. + +- There are unlocked-enabled worker function hosts in the system that + requires firmware update. The *Firmware Update Orchestration Strategy* + creation step will fail if there are no qualified hosts detected. + +- Firmware update is a reboot required operation. Therefore, in systems that + have the stx-openstack application applied with running instances, if the + migrate option is selected there must be spare openstack-compute \(worker\) + capacity to move instances off the openstack-compute \(worker\) host\(s\) + being updated. + + .. note:: + Administrative controller Swacts should be avoided during firmware + update orchestration. + +For more information, refer to the following: + +.. toctree:: + :maxdepth: 1 + + the-firmware-update-orchestration-process + firmware-update-operations-requiring-manual-migration diff --git a/doc/source/updates/kubernetes/the-firmware-update-orchestration-process.rst b/doc/source/updates/kubernetes/the-firmware-update-orchestration-process.rst new file mode 100644 index 000000000..62440766b --- /dev/null +++ b/doc/source/updates/kubernetes/the-firmware-update-orchestration-process.rst @@ -0,0 +1,106 @@ + +.. htb159043103329 +.. _the-firmware-update-orchestration-process: + +========================================= +The Firmware Update Orchestration Process +========================================= + +For an orchestrated firmware update you need to first create a *Firmware Update +Orchestration Strategy*, or plan for the automated firmware update procedure. + +You can customize the firmware update orchestration by specifying the following +parameters: + +.. _htb1590431033292-ul-pdh-5ms-tlb: + +- the host types to be updated; only **worker-apply-type** is supported + +- the alarm restriction mode; **strict** or **relaxed** where the **relaxed** + mode allows the strategy to be created while there are alarms present that are + not management-affecting + +- the concurrency of the update process; whether to firmware update hosts + **serially** or in **parallel** + +- the maximum number of worker hosts that can be updated together when + **parallel** mode is selected + + +For hosts that have the stx-openstack application running with active instances +and since the firmware update is a reboot required operation for a host, the +strategy offers **stop/start** or **migrate** options for managing instances +over the **lock/unlock** \(reboot\) steps in the update process. + +You must use the **sw-manager** |CLI| tool to **create**, and then **apply** the +update strategy. A created strategy can be monitored with the **show** command. +For more information, see :ref:`Firmware Update Orchestration Using the CLI +`. + +Firmware update orchestration automatically iterates through all +**unlocked-enabled** hosts on the system looking for hosts with the worker +function that need firmware update and then proceeds to update them on the +strategy :command:`apply` action. + +.. note:: + Controllers in Storage or Standard systems are not subject to firmware + updates. However, the controllers for an All-in-one \(|AIO|\)system can be + updated because they contain the worker function. Whenever controllers are + added to a strategy they are updated first; before the worker only hosts. + +After creating the *Firmware Update Orchestration Strategy*, you can either +apply the entire strategy automatically, or manually apply individual stages to +control and monitor the firmware update progress one stage at a time. + +When the firmware update strategy is **applied**, if the system is All-in-one, +the controllers are updated first, one after the other with a swact in between, +followed by the remaining worker hosts according to the selected worker apply +concurrency \(**serial** or **parallel**\) method. + +The strategy creation default is to update the worker hosts serially unless the +**parallel** worker apply type option is specified which configures the +firmware update process for worker hosts to be in parallel \(up to a maximum +parallel number\) to reduce the overall firmware update installation time. + +The firmware update strategy, with specified and default options is used to +create a reliable *Firmware Update Orchestration Strategy* that consists of a +number of execution stages. Each stage generally consists of installing the +firmware update while managing host instances, locking and then unlocking the +hosts for a subset of the worker function hosts on the system. The specific +steps involved in a firmware update for a single or group of hosts include: + +.. _htb1590431033292-ol-a1b-v5s-tlb: + +#. Alarm Query – is an update pre-check. + +#. Firmware update – non-service affecting update that can take over 45 minutes. + +#. Lock Host. + +#. Unlock Host – reboots the host so the updated image is used. + +Systems with stx-openstack application enabled could include additional +instance management steps. For more information, see :ref:`Firmware Update +Operations Requiring Manual Migration +`. + +On systems with stx-openstack application, the *Firmware Update Orchestration +Strategy* considers any configured server groups and host aggregates when +creating the stages to reduce the impact to running instances. The *Firmware +Update Orchestration Strategy* automatically manages the instances during the +strategy application process. The instance management options include +**start-stop** or **migrate**. + +.. _htb1590431033292-ul-vcp-dvs-tlb: + +- **start-stop**: where instances are stopped following the actual firmware + update but before the lock operation and then automatically started again + after the unlock completes. This is typically used for instances that do + not support migration or for cases where migration takes too long. To + ensure this does not impact the high-level service being provided by the + instance, the instance\(s\) should be protected and grouped into an + anti-affinity server group\(s\) with its standby instance. + +- **migrate**: where instances are moved off a host following the firmware + update but before the host is locked. Instances with **Live Migration** + support are **Live Migrated**. Otherwise, they are **Cold Migrated**. diff --git a/doc/source/updates/kubernetes/the-kubernetes-update-orchestration-process.rst b/doc/source/updates/kubernetes/the-kubernetes-update-orchestration-process.rst index 9b904842b..a2bb0b34e 100644 --- a/doc/source/updates/kubernetes/the-kubernetes-update-orchestration-process.rst +++ b/doc/source/updates/kubernetes/the-kubernetes-update-orchestration-process.rst @@ -152,7 +152,7 @@ Do the following to manage the instance re-location manually: - Manually perform Kubernetes version upgrade at least one openstack-compute worker host. This assumes that at least one openstack-compute worker host does not have any instances, or has instances that can be migrated. For more information on - manually updating a host, see :ref:`Kubernetes Version Upgrade + manually updating a host, see :ref:`Manual Kubernetes Version Upgrade `. - If the migration is prevented by limitations in the VNF or virtual diff --git a/doc/source/usertasks/index.rs1 b/doc/source/usertasks/index.rs1 new file mode 100644 index 000000000..e69de29bb diff --git a/doc/source/usertasks/kubernetes/index.rst b/doc/source/usertasks/kubernetes/index.rst index 58d53a67d..4f4722aa8 100644 --- a/doc/source/usertasks/kubernetes/index.rst +++ b/doc/source/usertasks/kubernetes/index.rst @@ -151,10 +151,9 @@ Adding an SRIOV interface to a container creating-network-attachment-definitions using-network-attachment-definitions-in-a-container - -************** +-------------- Metrics Server -************** +-------------- .. toctree:: :maxdepth: 1