...
...
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.
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. Further details about Policy/APPC interaction will be defined later, depending on which technologies we can leverage for Dublin release.
For example, if DD will be available, a user can define ModifyConfig parameters in CDS (extension of current CDT) and specify the parameter resolution in DD. During closed loop, Policy will just tell APPC to execute ModifyConfig against a specific VNF. APPC will then look at the VNF template (built with CDS) to retrieve the ModifyConfig parameters and use DD for their resolution. If DD will not be available, then ModifyConfig parameters could be defined in CLAMP and pushed to Policy during closed loop creation. Policy will then pass these parameters to APPC during closed loop execution. This is how the automated scale out use case is designed for Casablanca.
...
- 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).
...