WIP
Heat Template Structure
Today, the vFirewall use case is composed on two VNFs: i) one with the vFirewall and vSink VNF components (VNF-Cs), and ii) one with the packet generator (vPacketGen). Each VNF has its own Heat template. The Heat template that describes the vFirewall/vSink VNF also contains the private networks that connect elements in the overall service. Since Casablanca the heat templates have been restructured as follows: (https://github.com/onap/demo/tree/master/heat/vFW_NextGen/templates)
- One base Heat templates that includes the private networks and all the other common resources;
- One non-base Heat template per VNF-C, i.e. one template for the vFirewall, one for the vSink, and one for the vPacketGen.
This structure will allow users to leverage the macro instantiation workflow in SO, which deploys all the VNFs in a service in a single call. The macro instantiation workflow will install the base template first, and then all the other non-base templates.
This change to the Heat template structure has an impact on the way the Policy Engine will execute closed loop. Today, when a policy violation in the vFirewall use case is detected, the Policy Engine tells APPC to execute a corrective action against the vPacketGen VNF by providing the VNF UUID of the vPacketGen itself. Policy Engine will need to use the VF module UUID of the vPacketGen instead of the VNF UUID.
Leveraging CDS and Data Dictionary for Instantiation
The Controller Design Studio (CDS) has been supported in ONAP since Casablanca release. CDS allows a service designer to automate preload and to configure VF modules once they are created. SDNC will support collection of resource instantiation artifacts modelled at design time using CDS. SDNC will leverage the NETBOX capability to automate IP assignment and a Naming microservice for policy-driven resource naming generation. Default name values can also be used, if preferred. When the automated capabilities are used, SDNC automatically creates and assigns a name to a resource (e.g. a VM, network, etc.), based on predefined resolution strategies indicated in the Data Dictionary (DD). DD allows service designers and users to define how the parameters defined in the instantiation model can be resolved (automated capability, static value, or default value) and where the to retrieve resolution information from (MDSAL or database or other). Thanks to model-driven automation, the users can choose not to preload SDNC with VF module specific configuration before instantiating a VF module, but to rely on a fully automated approach.
Since Casablanca, we are using CDS to model the instantiation configuration of the VF modules that are part of the vFW use case. We won't need to preload configuration in SDNC before instantiating a VF module. We will create a blueprint that will allow CDS to automatically generate configuration at instantiation time. The CDS blueprints for vFW usecase can be accessed at: https://github.com/onap/ccsdk-apps/tree/casablanca/ms/controllerblueprints/application/load/blueprints/vFW. Tutorial on how to use CDS for vFW instantiation can be found here: vFW CDS Casablanca