Merge "Editorial updates - Admin Tasks, User tasks, and Updates and Upgrades Guides."
This commit is contained in:
Zuul
Gerrit Code Review
commit
bf352c9589
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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:<tag>
|
||||
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
|
||||
<setting-up-a-public-repository>`.
|
||||
|
||||
.. rubric:: |proc|
|
||||
|
||||
@ -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 <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
|
||||
<firmware-update-orchestration-using-the-cli>`.
|
||||
@ -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
|
||||
<displaying-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
|
||||
<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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 <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 <displaying-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.
|
||||
|
||||
@ -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
|
||||
----------------------------------------------
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
<configuring-kubernetes-update-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
|
||||
@ -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-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
|
||||
<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**.
|
||||
@ -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
|
||||
<manual-kubernetes-components-upgrade>`.
|
||||
|
||||
- If the migration is prevented by limitations in the VNF or virtual
|
||||
|
||||
0
doc/source/usertasks/index.rs1
Normal file
0
doc/source/usertasks/index.rs1
Normal file
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user