Browse Source

Administrator quide and other documentation

Some details of how to take Fenix into use.

Change-Id: I820aae66ba4bd0ce500c2d6797d852bbf39ef895
Signed-off-by: Tomi Juvonen <>
Tomi Juvonen 1 year ago
4 changed files with 70 additions and 8 deletions
  1. +14
  2. +40
  3. +8
  4. +8

+ 14
- 4
README.rst View File

@ -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
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
* Free software: Apache license
* Documentation:

+ 40
- 1
doc/source/admin/index.rst View File

@ -2,4 +2,43 @@
Administrators guide
Administrators guide of 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.
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.
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.

+ 8
- 0
doc/source/cli/index.rst View File

@ -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 '' and
'' 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.

+ 8
- 3
doc/source/user/architecture.rst View File

@ -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