How OPNFV Functest Tests Clearwater vIMS Deployment Using Cloudify – One Year Later
The third OPNFV Summit was a great success with 561 participants “connecting the global community” from the NFV ecosystem.
Since the last OPNFV Summit in Berlin in June 2016 many rivers have been crossed: 2 new releases have been produced, 2 plugfests have been organized, new features and test suites have been created! Service providers and many vendors indicated they started using OPNFV Danube test tools provided by the community.
The test case Cloudify/Clearwater has been introduced in Brahmaputra (release 2). This test case is detailed in a previous blog post.
Try the on-demand NFV lab test environment today! Go
This test case is the foundation for several subjects to address various pain points as defined by the OPNFV End User Advisory Group (EUAG):
- Functest VNF refactoring (using VNF onboarding testing abstraction)
- Software upgrade
- Multisite deployment
In OPNFV Brahmaputra release, we introduced the first complex realistic VNF test case named “cloudify_ims”. More than 1000 CI tests ran for this release performed on several platforms from the OPNFV Pharos federation. No major changes were done in Colorado, only some bugs were fixed. In Danube, some adaptations were made at the integration level to use the abstraction created to onboard the VNF for testing. Meanwhile the upstream community (especially the Cloudify orchestrator and the vIMS clearwater solution) is still evolving.
The main improvements can be described as follows:
- Cloudify 4.0 release integration
- Clearwater 122 (Ecthelion) release integration
- Full support of Keystone v3
- SNAPS integration (Testing framework developed by Cable Labs and integrated in OPNFV in Danube)
Since release 3.4, Cloudify provides a packaged image for OpenStack, which simplifies the orchestrator deployment in OpenStack. Moreover, the orchestrator also supports Keystone v3 API!
If you have an OPNFV platform, try it! (Choose the latest version of the functest container)
Upgrading an application on NFV systems should benefit from the cloud agility and should be realized in a different way compared with a legacy PNF. The VNF software upgrade is lightly addressed by open source communities and/or NFV specifications.
However, some recent activities are emerging:
- Cloudify supports the upgrade of a VNF Descriptor (blueprint) on an existing deployment
- Cloudify supports workflows for the upgrade of the VNF deployment
- ETSI/NFV is working on this topic to improve the NFV specification
- Heat supports HOT Template upgrade
During the last OPNFV Summit, one presentation dealt with this topic: “Devops Approach to Upgrade VNF”.
In the previous post, we mentioned that the need for a vIMS multisite deployment was indicated. Multisite is one of the pain points reported by OPNFV EUAG. At that time, several challenges were identified at the network level as well as the application and orchestration levels. One year later, it is now possible!
MetaSwitch Clearwater can now be shared between 2 sites with the OpenStack Tricircle project and Cloudify 4 automation. A demo has been set up in less than 2 months involving Huawei (OpenStack/Tricircle) and Cloudify/Clearwater (Orange). Another WebRTC application was used to demonstrate multisite capabilities.
This PoC demonstrates how to automatically deploy a complex VNF on multisite infrastructure and how to manage on-site failure. The multisite vIMS PoC is based on:
- VNF: MetaSwitch Clearwater IMS – release 107
- Orchestrator: Cloudify Manager – release 4.0
- DNS: OpenStack Designate (with Bind)
- Test: clearwater-live-test (included in OPNFV Functest container in Brahmaputra)
- VIM + NFVI: 3 OpenStack Regions with Tricircle
This PoC focuses on the VNF high availability. In Region1, sit all the “management” components such as DNS or Cloudify Manager, while other vIMS components are deployed in HA mode in both Region2 and Region3.
This shared VNF deployment was executed thanks to the last release of Cloudify. A specific VNF descriptor was created for the multisite deployment. All network components must be created in the “central region” and other components in the other regions. The Cloudify OpenStack plugin was also updated with minor adaptations to support Tricircle. For example, some code was needed for the floating ip association between the server port and the floating ip.
The Cloudify plugin modularity enables the update of the OpenStack plugin to support Tricircle and the Cloudify full set of features demonstrates how Cloudify can be used to support the multi-region deployment.
For general details about the demo, please watch the video “Shared Networks to Support VNF High Availability Across OpenStack Multi Region Deployment.”
The last year was really exciting. Most of the pain points can now be addressed. Software upgrade and multisite are still challenging. New OPNFV projects (Bamboo for analytics, Energy) are new challenges applicable to the Cloudify/Clearwater testcase.
We may also see additional orchestrators follow this example. In Danube we saw the first Open-O/Clearwater, Openbaton/openIMS, Cloudify/vRouter test case reusing the same methodology for onboarding. Integration with ONAP will be a new challenge.