Page Comparison

Model

...

-driven HPA

The "model-driven" in the title above refers to a data model for definition of VNF descriptors, as specified by the ETSI NFV SOL001 specification. Starting with Casablanca, the term "onboarding model" may also be used to this data model. The data model is based on a TOSCA Simple YAML 1.1/1.2 language encoding. In the future (post-Casablanca) this data model may also be encoded using YANG. The data model is persisted as an artifact in the TOSCA CSAR flle (zip archive) as specified by the ETSI NFV SOL004 specification. The specification of HPA requirements is incorporated in the VNFD definition.

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

Model driven HPA Model driven HPA needs following enhancements:

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

Affected projects:

• Modeling project
  • Define HPA model (TOSCA definitions)
• VNF SDK  during service creation

Model-driven HPA User Story

• VNF developers create a VNFD as part of the VNF package. This may be done by hand or using visual design tools. Once the package has been created, it is validated using the VNFSDK tools, or by other equivalent means. 
• VNF developers use the VNFSDK tools will validate the structure and integrity of the CSAR file and the syntactic/semantic validity of the VNFD, including the HPA requirements.
• ONAP operators onboard VNFs into ONAP. As part of the onboarding process, the VNF undergoes a set of  operator specific acceptance tests. If the VNF acceptance is successful, the VNF becomes part of the design time catalog.
• As part of VNF instantiation, the VNFD contents is propagated to the Policy Framework.
• The Policy Framework translates the HPA requirements specified within the VNFD into OOF placement policies. 
• The OOF subsequently uses these policies to determine proper homing and placement of VNF components.

Model-driven HPA Work Items

• Validation of HPA requirements contained in the VNFD
• On-boarding of VNFDs into SDC
• Propagation of VNFDs from SDC to Policy
• Translation of VNFD contained HPA requirements into OOF policies

Note - It is assumed that no changes to OOF and SO are required from the model-driven HPA perspective.

Affected Projects

• Modeling Subcommittee
  • Endorse the R3 resource data model (HPA included)
• VNFSDK 
  • Verify the HPA model semantically and syntactically
• SDC :
  • Ensuring that HPA additions does do not affect the functionality
  • Propagation of VNFDs to POLICY
• POLICY framework
  • Look for new models
  • Download models
  • Get hold of HPA information
  • Create/Delete/Modify HPA Translation of HPA requirements into OOF policies

Prerequisites:

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

...