Skip to content

Cloudify And ONAP

Jump to bottom
DeWayne Filppi edited this page Jun 19, 2019 · 21 revisions

Introduction

Cloudify and ONAP have a long history and a relationship that continues. Cloudify is a founding member of ONAP and continues contributions on several fronts. This post describes the current uses and integrations of Cloudify in ONAP.

DCAE - Data Collection, Analytics, and Events

The DCAE project concerns itself with service metrics and event collection, and analytics. Platform components of DCAE, including the Cloudify Manager, are deployed via Helm as defined in the OOM project in the dcaegen2 chart. For more details see the documentation.

DCAE service level orchestration is provided by Cloudify, which manages the full data collection and eventing infrastructure lifecycle. Data collection must be initiated by the DCAE on demand from [CLAMP](https://wiki.onap.org/display/DW/CLAMP+Project)(closed loop automation), or DCAE's deployment API on a per service basis. Required Cloudify blueprints are parameterized by JSON inputs during SDC model definition, and deployed via Cloudify to initiate data collection, analytics and events as specified. Services include [Holmes](https://wiki.onap.org/pages/viewpage.action?pageId=5734499), [TCA](https://wiki.onap.org/display/DW/TCA+application)(analytics), [VES](https://docs.onap.org/en/casablanca/submodules/dcaegen2.git/docs/sections/services/ves-http/)(metrics streaming), [SNMP trap collection](https://docs.onap.org/en/casablanca/submodules/dcaegen2.git/docs/sections/services/snmptrap/) and [others](https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/architecture.html).

SO - Service Orchestration

The SO project concerns itself with top level orchestration of network services in ONAP. The SO conceptually breaks down network functions into "VDUs" (VNF deployment units). The VDU concept was invented to permit individual VNFs to span multiple compute instances. Initially the only downstream orchestrator for VDUs was Openstack HEAT. To enable for more flexibility, the concept of a VDU plugin was introduced with Cloudify being an implementation (along with HEAT). This enables the greater flexibility of TOSCA and Cloudify plugins, far beyond Openstack, to be brought to bear on the infrastructure orchestration domain. While most of the code for this integration has been part of recent releases, work continues to finalize the integration in the near future.

Also, recent contributions to the SO to introduce an ETSI VNFM adapter will provide another avenue for Cloudify to plug into ONAP via it's own ETSI native API integration (coming later this year) as a VNFM (both vendor specific and generic).

CCSDK

The CCSDK project holds shared libraries and artifacts that are used across ONAP. Cloudify has a couple of utilities available in CCSDK: the platform base installation, the DMaaP Cloudify plugin, and the Helm Cloudify plugin.

Platform base installation

The platform base installation starts a VM in Openstack and installs a Cloudify manager on it. The new manager in turn starts three VMs running Consul in high availability mode. This served as the part of the DCAE platform install through the Casablanca release.

DMaaP plugin

The DMaaP Cloudify plugin is a Cloudify plugin that defines TOSCA types and relationships that automate the interoperation with DMaaP subsystem. For example, lifecycle management of DMaaP message router topics and feeds, connection to existing topics and feeds, establish feed bridges, etc.

Helm plugin

The Helm plugin. The helm plugin was intended to support deployment scenario of stand-alone application similar to capability offered under OOM. With this plugin integration, any charts packaged under ONAP OOM can be deployed through DCAE platform in ONAP. This provides an opportunity for operators to use a single orchestration through Cloudify for deploying both Helm and TOSCA work flows if required.

References

Clone this wiki locally