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. Cloudify serves both to orchestrate DCAE platform components, as well as per service components to support instrumentation and analytics.
DCAE platform bootstrap is performed by Cloudify (Docker container), after itself being bootstrap by Helm. The Cloudify manager starts platform components such as Holmes, TCA(analytics), VES(metrics streaming), SNMP trap collection and others.
DCAE service level orchestration is also 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 the DCAE's deployment API on a per service basis. Required Cloudify blueprints are parameterized by JSON inputs, and deployed via Cloudify to initiate data collection, analytics and events as specified.
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).