Model Driven HPA

In R2, HPA requirements for each VDU (VNFC) of VNF are represented as a policy.  Though policy driven HPA will continue to be there in R3,  our intention is to auto-create HPA policies from VDU model of the service. Intention is to avoid creation of policies outside of model. Since TOSCA, industry standard, is chosen to represent model,  even VNF vendors can provide the VNF HPA requirements. 

Model driven HPA needs following enhancements:

• Creation of  HPA policies dynamically from the VNFD/VDUD
• Verification of HPA requirements defined in the VNFD/VDUD during service creation
  
  

Affected projects:

• Modeling project
  • Define HPA model (TOSCA definitions)
• VNF SDK 
  • Verify the HPA model semantically and syntactically
• SDC :
  • Ensuring that HPA additions does not affect the functionality
• POLICY framework
  • Look for new models
  • Download models
  • Get hold of HPA information
  • Create/Delete/Modify HPA policies

Prerequisites:

• SO implementing TOSCA models
• Creation of TOSCA models for existing use cases (vFW/vDNS and vCPE)

SRIOV NIC Support

HPA feature in OOF facilitates placing VDUs on the site that has compute nodes supporting needed SRIOV-NIC cards. Operators like to have flexibility of placing the workloads on non SRIOV-NIC machines in case there are no matching profiles. In HEAT templates, there is a challenge to have this kind of flexibility. HEAT templates are normally created for SRIOV-NIC as design time as there is special HEAT logic for SRIOV-NICs.  If non-SRIOV site is chosen at run time,  then this special HEAT  information needs to be replaced dynamically with normal vSwitch information  based on the results from OOF.

• SO/Multi-Cloud 
  • Check the profile returned by OOF.
  • For each CP of VDUs/VNF, 
    • Check whether that CP requires SRIOV-NIC and verify whether the NIC supported by that profile.
  • If above condition is true for all CPs, then there si no change required in HEAT information.
  • If not, modify appropriate portion of HEAT information from SRIOV-NIC to normal vswitch.

Features that are being carried over from R2

OOF Enhancements

R2 OOF returns the VNF placement information by giving best cloud region and set of compute profiles in that cloud-region for constituent VDUs of the VNF.  R2 OOF does this by matching the operator defined policies with the capabilities of cloud-regions. Some features could not be implemented in R2.  Intention is to implement following in R3

• Logging & statistics and Visualization
  • Ability for deployment administrator to view the compute profiles used by VNFs over time (historical data)
  • VNFs that could not be placed due to non-matching compute profiles.
  • VNFs that are placed, but the optimal compute profile could not be found.
  • VNFs that are placed with various scores.
• Best site selection with respect to compute profiles:  R2 has ability to select the best compute flavor on per site basis. That is, HPA filter on per input candidate site, checks whether there is any matching compute profile. If there is one, it stops searching on rest of candidates.  In R3, intention is to search through all input candidate sites,  get the best compute profile in each site and select the site whose compute profile (combined) score is highest.  
• Ensuring that results are consistent irrespective order of the filter execution:  Currently, HPA filter is run last.  If HPA filter is run first, the result should be same.  There are few enhancements required in OOF execution order of filters. It may be that, there are two phases of execution. First phase requires selection of candidate list and second phase is to select the best of all the selected sites.

SO Enhancements

HPA functionality is tested with vCPE use case in R2.  As we understand,  SO has various workflows that could be different for various use cases. In R3, intention is to ensure that

• HPA compute profile selection for vFW and vDNS use cases.
• ??

Multi-Cloud Enhancements

• Adding more HPA features (e,g OVS DPDK)
• ???