Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

This is a sub project of CIRV about the Pod Descriptor File (PDF) definition, based on PDF history definition in OPNFV, we name it as PDF3.0. It's expected to build up a uniformed data model which cover all necessary information in the entire lifecycle stage in the NFV construction, like planning, configuration, pre/post checks, deployment, verification/validation etc. By using the common model, all participants of different stage roles could archive related function. It targets to reduce costs in kinds of adaptation during the final integration and deployment. 

...

PDF is defined in CNTT-RI1 chapter6: installer requirement, the descriptor should specify both hardware and software information for NFVI installation, including resource pool information, parameters for each server and switch, network configuration, and parameters for VIM-storage integration process.  Please refer to CNTT-RI1 documents for the details of PDF definition.(PDF 2.0) https://github.com/cntt-n/CNTT/blob/master/doc/ref_impl/cntt-ri/chapters/chapter06.md


Architecture

Gliffy
macroId4c6bdb27-8ad4-4d34-bf94-a3db61cd145b
displayNamePDF Specification To implementation
namePDF Specification To implementation
pagePin2
 


Implementation

There's no limitation on how to implement PDF, you can use the format of descriptor could be json or csv, whichever works for your tool, as for the content of the descriptor, you can also customize the structure, like you can use flat version of data, or you can group data entries by the same properties.

Flat version:

Hierarchical Version: 

Architecture

Gliffy
macroId4c6bdb27-8ad4-4d34-bf94-a3db61cd145b
displayNamePDF Specification To implementation
namePDF Specification To implementation
pagePin2

...

Taking server information as example, the flat version could be:

{
"GLOBAL_SETTING": {
},
"SERVER": [
//flat version for table server, using list to describe all servers, each object is used to specify full parameters for each server
{
"NAME": "SERVER1",
"VENDOR": "",
"SKU": "",
"MODEL": "",
"SN": "",
"RES_POOL": "",
"BMC_IP": "",
"BMC_GATEWAY": "",
"BMC_MASK": "",
"BMC_SUBNET": "",
"BMC_USR": "",
"BMC_PWD": "",
"SERVICE_IP": "",
"SERVICE_GATEWAY": "",
"GROUP_NAME": "",
"HW_REGION": "",
"MODULE_NAME": ""
},
{
"NAME": "SERVER2",
"VENDOR": "",
"SKU": "",
"MODEL": "",
"SN": "",
"RES_POOL": "",
"BMC_IP": "",
"BMC_GATEWAY": "",
"BMC_MASK": "",
"BMC_SUBNET": "",
"BMC_USR": "",
"BMC_PWD": "",
"SERVICE_IP": "",
"SERVICE_GATEWAY": "",
"GROUP_NAME": "",
"HW_REGION": "",
"MODULE_NAME": ""
}
],
"SWITCH": [
//same mechanism can be applied to switch.
]
}


Hierarchical Version, group servers by same vendor, same BMC_GATEWAY, same usage: 


{
"GLOBAL_SETTING": {
},
"SERVER": {
// customized hierarchical data entries
"STORAGE": {
"VENDOR": "",
"SKU": "",
"MODEL": "",
"SN": "",
"BMC_USR": "",
"BMC_PWD": "",
"BMC_GATEWAY": "",
"BMC_MASK": "",
"NODES": [
{
"NAME": "node1",
"BMC_IP": "",
"SERVICE_IP": "",
"SERVICE_GATEWAY": "",
"HW_REGION": "",
"MODULE_NAME": ""
},
{
"NAME": "node2",
"BMC_IP": "",
"SERVICE_IP": "",
"SERVICE_GATEWAY": "",
"HW_REGION": "",
"MODULE_NAME": ""
}
]
},
"SERVICE": {

},
"CONTROL": {

}
},
"SWITCH": [
//same mechanism can be applied to switch.
]
}


For more information, please refer to: https://github.com/opnfv/cirv-sdv/tree/master/sdv/pdf