...
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 followfollows: (https://github.com/onap/demo/tree/master/heat/vFW_NextGen/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. (Pamela Dragosh Plz confirm) 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.
...
Since Casablanca, we are using CDS to model the instantiation configuration of the VF modules that are part of the vFW use case. In this way, we 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
...
Today, Policy hardcodes the entire body of the operation that APPC has to execute against the VNF during closed loop.
ModifyConfig action including the parameters and their resolution will be defined in CDS as described above. We will implement CDS API model implementation and actor implementation in policy so that we can either directly invoke CDS to push the NETCONF payload to the vPacketGen VNF or invoke APPC to execute ModifyConfig against the traffic generator VNF.
(Pamela Dragosh Plz confirm the below items.) 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.
Pamela Dragosh - we want to also deprecate the old API for ModifyConfig and use APPC's latest API interface if possible.
For example, if DD will be available, as described above: a user can define ModifyConfig parameters in CDS (extension of current CDT) using DD 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.
...