Cloudify And ONAP
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.
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(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, TCA(analytics), VES(metrics streaming), SNMP trap collection and others.
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. <> 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).