...
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.
...
Leveraging CDS and Data Dictionary
The Controller Design Studio (CDS) will be contributed to ONAP as part of Casablanca release. CDS extends the current capabilities of the Controller Design Tool (CDT), allowing a service designer to create both a VNF template (as in Beijing) and a configuration template that will be used to configure VF modules once they are created. SDNC will support collection of resource instantiation artifacts modeled 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 or database). 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 Dublin, we plan to use CDS and DD (if available) 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.
For Dublin, we will model the vFW interfaces with CDT. This will deprecate the current APPC ModifyConfig API call from Policy to APPC and upgrade to APPC's latest LCM API. Further details about Policy/SO/APPC interaction will be defined later, depending on which technologies (e.g. DD) we can leverage for Dublin release.
Removing ModifyConfig Parameters from the Policy Template
Today, Policy hardcodes the entire body of the operation that APPC has to execute against the VNF during closed loop. For Dublin, we plan to remove this limitation: Policy will receive the ModifyConfig parameters from CLAMP and pass them to APPC.
- The parameters of the ModifyConfig API should also be made available when CLAMP builds the Operational Policy. This will remove hard-coding of the parameters in the Policy Template.
- Addition of guard policies to restrict the number of restarts in a time window (Stretch)
- Addition of another Control Loop to restart the vPacketGenerator when it hangs (Stretch - need investigation to see if feasible)
- PLD via Phil Weir - add APPC HealthCheck before restart. Restart would only run if the any HealthCheck failure occurs (eg. the VNF really is hung).
- Future: Add in Control Loop Coordination of both Control Loops. See the following for more details: https://wiki.onap.org/pages/viewpage.action?pageId=35523671&preview=/35523671/36965215/CLC_11_July_2018.pdf
...