Administrator quide and other documentation
Some details of how to take Fenix into use. Change-Id: I820aae66ba4bd0ce500c2d6797d852bbf39ef895 Signed-off-by: Tomi Juvonen <tomi.juvonen@nokia.com>
This commit is contained in:
parent
244fb3ced0
commit
cbe9dde0e6
18
README.rst
18
README.rst
|
@ -17,11 +17,21 @@ Application can have a time window to finish what he is doing, make own action
|
|||
to re-instantiate his instance or have Fenix to make migration. Also scaling
|
||||
application or retirement will be possible.
|
||||
|
||||
As Fenix will have project specific messaging with information about instances
|
||||
As Fenix has project specific messaging with information about instances
|
||||
affected towards application manager, it will also have admin level messaging.
|
||||
This messaging can tell what host is down for maintenance, so any
|
||||
infrastructure components can have this information. Special case for this
|
||||
would also be telling about adding or removing a host.
|
||||
This messaging can tell what host is down for maintenance, back in use, added
|
||||
or retired. Any infrastructure component can catch this information as needed.
|
||||
|
||||
Fenix also work with "one click". Infrastructure admin just creates the
|
||||
workflow session he wants and all needed software changes are automatically
|
||||
downloaded, workflow is run to wanted hosts according the request and
|
||||
depending on how the used workflow plug-in and action plug-ins are
|
||||
implemented.
|
||||
|
||||
In the NFV Fenix needs to be supported by infrastructure admin UI, VNFM and
|
||||
VNF implementation. Fenix itself should be integrated to infrastructure
|
||||
to be used it the infrastructure maintenance, upgrade, scaling and life-cycle
|
||||
operations.
|
||||
|
||||
* Free software: Apache license
|
||||
* Documentation: https://fenix.readthedocs.io/en/latest/index.html
|
||||
|
|
|
@ -2,4 +2,43 @@
|
|||
Administrators guide
|
||||
====================
|
||||
|
||||
Administrators guide of Fenix.
|
||||
Fenix
|
||||
=====
|
||||
|
||||
Fenix itself should be deployed to the infrastructure controller- or
|
||||
manager-node and be used for any cloud infrastructure maintenance, upgrade,
|
||||
scaling or life-cycle operations.
|
||||
|
||||
VNF and VNFM
|
||||
============
|
||||
|
||||
In NFV use case the VNF and VNFM need to support Fenix to optimize the workflows
|
||||
and to guarantee zero impact to VNF during different infrastructure operations.
|
||||
This means instance and instance group constraints and the interaction
|
||||
with Fenix. Best optimization will be if the VNF can be scaled according to its
|
||||
current utilization level. This will result to smallest possible maintenance
|
||||
window while keeping the zero impact on VNF service.
|
||||
|
||||
Infrastructure Admin UI
|
||||
=======================
|
||||
|
||||
Infrastructure admin UI needs to support Fenix. UI needs to be able to call
|
||||
the Fenix admin APIs and preferably to listen Fenix admin events. UI should
|
||||
be able to call different infrastructure maintenance and upgrade workflows
|
||||
with needed parameters. APIs and events also give possibility to have
|
||||
a detailed information of the workflow progress and to troubleshoot possible
|
||||
errors. In complex clouds errors can be still simple and quickly corrected
|
||||
even manually. In this kind of special case the UI can also support updating
|
||||
Fenix workflow session to continue exactly to where it left.
|
||||
|
||||
Integration
|
||||
===========
|
||||
|
||||
The above mentioned UI, VNF and VNFM are currently not in scope of Fenix.
|
||||
The implementation should be in other open source project or own proprietary
|
||||
solution. Currently at least the OpenStack Tacker is looking to support Fenix.
|
||||
|
||||
Fenix itself also need to be tested and for that there is some kind of command-line
|
||||
implementation for the above functionality made under Fenix 'tools'. Implementation
|
||||
aims to have the ability to test the Fenix sample workflows with sample application
|
||||
(VNF). It also gives the idea what needs to be supported.
|
||||
|
|
|
@ -3,3 +3,11 @@ Command line interface reference
|
|||
================================
|
||||
|
||||
CLI reference of Fenix.
|
||||
|
||||
Currently Fenix do not implement CLI. Real product integration is
|
||||
expected to have GUI and VNFM (application manager) to support Fenix.
|
||||
Currently OPNFV Doctor maintenance test case implements infrastructure
|
||||
admin and VNFM behavior. In Fenix you can find 'infra_admin.py' and
|
||||
'vnfm.py' that implements the same and are always up-to-date to be tested
|
||||
against Fenix example workflows. Those are anyhow just for testing sample
|
||||
application, but works to get the idea for a product implementation.
|
||||
|
|
|
@ -7,8 +7,9 @@ Fenix Architecture
|
|||
Fenix is an engine designed to make a rolling infrastructure maintenance and
|
||||
upgrade possible with zero downtime for the application running on top of it.
|
||||
Interfaces are designed to be generic, so they can work with different clouds,
|
||||
virtual machines and containers. The first use case is with OpenStack and VMs,
|
||||
but the aim is to have a wider scope, like edge (Akraino) and Airship.
|
||||
virtual machines and containers. Current workflows are for OpenStack and
|
||||
Kubernetes, but the workflow plug-in implementation defines what kind
|
||||
of cloud you want to support.
|
||||
|
||||
The key in Fenix providing the zero downtime is to have an ability to
|
||||
communicate with an application manager (VNFM). As the application is aware of
|
||||
|
@ -55,10 +56,14 @@ plug-ins can be implemented for different clouds and deployments.
|
|||
|
||||
**action plug-ins** are called by the workflow plug-in. It is possible to have
|
||||
different type of plug-ins, and if there is more than one of a specific type,
|
||||
one can also define the order they are executed:
|
||||
one can also define the order they are executed. These types are currently in
|
||||
use in the Fenix example workflows. You can always define your own type
|
||||
according to your workflow implementation:
|
||||
|
||||
* **pre** plug-in is run first
|
||||
* **host** plug-in is run for each host
|
||||
* **compute** plug-in is run on each compute host
|
||||
* **controller** plug-in is run on each controller host
|
||||
* **post** plug-in is run last
|
||||
|
||||
There is a possibility to define 'metadata' to further indicate plug-in
|
||||
|
|
Loading…
Reference in New Issue