openstack/tacker-specs
Code Issues Proposed changes

Fenix plugin for rolling upgrades in Tacker

Browse Source 
This spec describes a Fenix plugin for rolling upgrades in Tacker

Blueprint vnf-rolling-upgrade
storyborad https://storyboard.openstack.org/#!/story/2005220

Co-Authored-By: Jangwon Lee <jangwon.lee@dcn.ssu.ac.kr>

Change-Id: Idf75f2519a21ebca9aca7d7e150757dc0a336755
This commit is contained in:
hyunsikYang
2019-03-16 16:39:26 +09:00
parent 6dc97cc61f
commit 8f7ad05e09
1 changed files with 313 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

313
specs/train/vnf-rolling-upgrade.rst Normal file
View File

@@ -0,0 +1,313 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
===========================================
Fenix plugin for rolling upgrades in Tacker
===========================================
https://blueprints.launchpad.net/tacker/+spec/vnf-rolling-upgrade
https://storyboard.openstack.org/#!/story/2005220
This spec describes a Fenix plugin for rolling upgrades in Tacker
Problem description
===================
For Host upgrade or maintenance, administrator needs to migrate
the services running on the host, or provides services through
a redundancy model such as ACT-STB.
In order to do this, interworking with MANO such as Tacker,
which manages the life cycle of VNF, is essential.
Fenix project suggested the procedure to work with MANO
for maintenance/upgrade [#f1]_.
With Fenix, tacker can support maintenance procedure
without a service stop. In addition, if VNF provider supports
VNF upgrade/maintenance, it also supported in this feature.
Therefore, this feature helps the maintenance/upgrade procedure
for Host maintenance/upgrade with Fenix.
This blueprint is proposed Host maintenance/upgrade mode
by leveraging Fenix(rolling infrastructure maintenance,
upgrade and scaling).
Proposed change
===============
The scope of this spec focuses on:
* Designing a Fenix Plugin for VNF Maintenance. Whereby, an VNF Maintenance
driver is designed to collect events triggered by the Ceilometer/aodh.
In this spec, the VNF Maintenance driver subscribes event from ceilometer
/AODH with 'maintenance.planned' [#f2]_.
* Defining maintenance policies using the TOSCA Policy format [#f3]_.
::
The VNF maintenance framework:
+-----------------------------------+
| |
| |
| +-----------------+ |
| | VNFM / TOSCA | |
| | | |
| +--------^--------+ |
| | |
| +--------v--------+ |
| | | | +----------------+
| | Fenix Plugin | | | fenix client |
| | | | +----------------+
| +-^-^-------^-^---+ | |
| | | | | | |
| +-v-v-------v-v---+ | |
| | Ceilometer/AODH | | +-------v--------+
| | |<--------------| Fenix-Engine |
| +-----------------+ | +----------------+
+-----------------------------------+
The TOSCA scheme could be defined as the following:
**tosca.policies.tacker.Maintenance**
.. code-block:: yaml
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Maintenance VNF with Fenix
metadata:
template_name: tosca-vnfd-maintenance
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
capabilities:
nfv_compute:
properties:
num_cpus: 2
mem_size: 2048 MB
disk_size: 15 GB
properties:
name: VDU1
image: ubuntu18.04
availability_zone: nova
mgmt_driver: noop
maintenance: true
CP11:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
order: 0
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: Tacker
maintenance_url will be created by webhook in Tacker as the following:
.. code-block:: ini
v1.0/vnfs/<vnf-uuid>/maintenance/<project_id>
**vnf-uuid** represents identity of the VNF.
**maintenance** means that this URL is used for maintenance.
**project_id** represent the project to which the generated VNF belongs.
Maintenance Procedure
=====================
When VNF is created using VNFD, VNF generates 'Maintenance URL'
to register event to AODH. Then, when the user requests maintenance,
the Notification message generated by Fenix Engine is delivered to
ADOH and the event occurs.
When an event occurs, Tacker performes the action
(e.g., VNF reinstantiation) requested from the Fenix engine to the
Tacker via Tacker-plugin.
Maintenance procedure can be divided into two cases.
1. VNF is impacted due to the infrastructure (host) maintenance
or upgrade and might need to scale down VNF during the
operation. Upgrading the VNF is also possible at the same.
2. VNF is impacted due to the infrastructure (host) maintenance
or upgrade. Upgrading the VNF is also possible at the same.
In the case of first, Tacker follows default procedure of Fenix and
supports preparation procedure for Host Maintenance such as scaling
down VNF and migrating instances to another host to have an empty
host for infrastructure rolling maintenance or upgrade.
The procedure is below:
::
+--------+ +--------+ +-------+ +-------+
| Tacker | | AODH | | Fenix | | admin |
+--------+ +--------+ +-------+ +-------+
| | | |
VNF Creation | | |
| | | |
|--Register Alarm -->| | |
| maintenance.planned | |
| Event_type : maintenance.* |<-MAINTENANCE-|
| |<----MAINTENANCE-----| |
| | | |
| event | |
|<----MAINTENANCE----| | |
| | | |
|----------------ACK_MAINTENANCE---------->| |
| | | |
|<---------------IN_SCALE------------------| |
| | | |
Scaling | | |
|--------------ACK_IN_SCALE--------------->| |
| | | |
|<-----------PREPARE_MAINTENANCE-----------| |
| | | |
|----------ACK_PREPARE_MAINTENANCE-------->| |
| | | |
|<-----------ADMIN_ACTION_DONE-------------| |
| | | |
|<---------PLANNED_MAINTENANCE-------------| |
| | | |
|-------ACK_PLANNED_MAINTENANCE----------->| |
| | | |
|<--------MAINTENANCE_COMPLETE-------------| |
| | | |
|-------ACK_MAINTENANCE_COMPLETE---------->| |
In the case of second, Tacker doesn't need to follow all of the
default procedure. It is only performing VNF maintenance action
such as changing the path from STB to ACT, instance re-instantiation
or migrating existing instance to already maintained host.
::
+--------+ +--------+ +-------+ +-------+
| Tacker | | AODH | | Fenix | | admin |
+--------+ +--------+ +-------+ +-------+
| | | |
VNF Creation | | |
| | | |
|--Register Alarm -->| | |
| maintenance.planned | |
| Event_type : maintenance.* |<-MAINTENANCE-|
| |<----MAINTENANCE-----| |
| | | |
| event | |
|<----MAINTENANCE----| | |
| | | |
|----------------ACK_MAINTENANCE---------->| |
| | | |
|<-----------ADMIN_ACTION_DONE-------------| |
| | | |
|<---------PLANNED_MAINTENANCE-------------| |
| | | |
|-------ACK_PLANNED_MAINTENANCE----------->| |
| | | |
|<--------MAINTENANCE_COMPLETE-------------| |
| | | |
|-------ACK_MAINTENANCE_COMPLETE---------->| |
Alternatives
------------
None
Data model impact
------------------
None
REST API impact
---------------
**POST on v1.0/vnfs/<vnf-uuid>/maintenance/<project_id>**
Security
--------
None
Notifications impact
--------------------
User triggers maintenance session and Tacker performs the action
for maintenance.
Other end user impact
---------------------
None
Performance impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Hyunsik Yang <yangun@dcn.ssu.ac.kr>
Other contributors:
Jangwon Lee <jangwon.lee@dcn.ssu.ac.kr>
Work Items
----------
#. TOSCA Template definition for Maintenance
#. URL Creation for Maintenance Alarm Registration
#. Fenix Plug-in Implementation for Fenix API
#. Unit and functional tests
#. Documentations
Dependencies
============
Tacker defines all Maintenance APIs according to APIs defined in Fenix.
Tacker supports down scaling of VNFs.
Testing
========
- Maintenance VNF testing
- AODH Registration with Maintenance
- Maintenance event Alarm
Reference
=========
.. [#f1] https://wiki.openstack.org/wiki/Fenix
.. [#f2] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf
.. [#f3] https://docs.openstack.org/aodh/latest/contributor/event-alarm.html