...
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.
Updating the 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:
- 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. 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).
Leveraging CDS and Data Dictionary
...
For 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.
...
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).
Adding of Guard Policies
Guard policies can be added (stretch goal) to regulate the frequency of operations in a given time frame, for example restricting the number of traffic adjustments in the next X minutes.
Adding Closed Loops
In Dublin we can extend the set of closed loops and actions executed against the VNF. One possible scenario is to restart the VM that hosts the traffic generator VNF (vPacketGen) if/when it stops sending traffic. Other closed loops (e.g. monitoring the health status of the VNF via APPC) are under consideration, but they represent a stretch goal at the moment.
Adding Control Loop Coordination
Control Loop Coordination is useful when multiple closed loop are defined and the Policy Engine must ensure that no more than one control loop runs at a time. This extension is being evaluated for Dublin
...
. See the following for more details: https://wiki.onap.org/pages/viewpage.action?pageId=35523671&preview=/35523671/36965215/CLC_11_July_2018.pdf