...
The vFirewall is the easiest to use amongst all the use cases and is used heavily for automated regression by the Integration team and by ONAP users who test and try out the platform. Currently, the use case is out-of-date. The goal is to bring it up to standard with other use cases.
...
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. For Dublin, we are considering to reshape the Heat templates in the following way:Since Casablanca the heat templates have been restructured as follow: (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 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. If we decide to reshape the Heat templates as described above, Policy Engine will have to use the VF module UUID of the vPacketGen instead of the VNF UUID. Policy doesn't have this capability right now, so reshaping the Heat templates is currently under investigation. A possible approach could be to reshape only the vFirewall/vSink Heat template and leave the vPacketGen Heat template as is. This, however, may complicate the adoption of CDS technologies (see below), which would have to deal with cross references in Heat templates of elements at different levels (i.e. VF module vs. VNF).
Finally, Heat templates should be follow the ONAP VNF Guidelines and pass VNF Validation.
Leveraging CDS and Data Dictionary for Instantiation
The Controller Design Studio (CDS) will be contributed to ONAP as part of has been supported in ONAP since Casablanca release. CDS extends the current capabilities of the Controller Design Tool (CDT), allowing allows a service designer to create both a VNF template (as in Beijing) and a configuration template that will be used automate preload and to configure VF modules once they are created. SDNC will support collection of resource instantiation artifacts modeled modelled at design time using CDS. SDNC will leverage the NETBOX capability (planned for Casablanca) 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 (MSDAL 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.
For DublinSince Casablanca, we plan to use CDS and DD (if available) are using CDS to model the instantiation configuration of the VF modules that are part of the vFW use case. In this way, 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.
Modeling VNF Interfaces with CDT
Being the ONAP controllers VNF-agnostic and model-based, the user is required to create a VNF template using the Controller Design Tool (CDT). The template describes the operations that can be executed against a VNF (e.g. scale out, health check, modify configuration, etc.), the protocols that a VNF supports, port numbers, VNF APIs, and credentials for authentication. ONAP controllers use these templates to “learn” about specific VNFs and the supported operations.
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
Define ModifyConfig action in CDS for Post-Instantiation
Create CDS package (CBA: controller blueprint archive) that defines ModifyConfig action. The inputs that we envision are VNF ID, Port number and credentials for authentication. As a part of this package designer will define the ModifyConfig action by providing golden templates (XML Netconf template) along with a mapping file defining what values to resolve and a python script to resolve the configlet and apply it using NETCONF. An example of deploying configuration to a NETCONF server using CDS can be found here: https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Scripts/python/ConfigDeploy.py
The recording can be accessed at: Presentation#ONSNA2019For Dublin, we will model the vFW interfaces with CDS (extension of current CDT). This will deprecate the current APPC ModifyConfig API call from Policy to APPC and upgrade to APPC's latest LCM API.
Removing ModifyConfig Parameters from the Policy Template
...