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 [1]. 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’ [2].
Defining maintenance policies using the TOSCA Policy format [3].
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
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:
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.
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.
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
