Anuket Project

Overview

Pod Description File(short for PDF),  is a sub project of CIRV, it is based on PDF definition history from OPNFV, currently PDF has entered 2.0 version. The goal is to set up a uniformed data model which will cover all necessary information in the entire lifecycle of NFV construction, including resource pool information, cabinet information, hardware information, and parameters for resource planning, hardware configuration, pre-deployment checks, deployment, verification, and etc. By using the common resource pool data model, all participants of different stage could  read from the same configuration file . It targets to reduce costs of adaption in multi-vendor NFV solution of  during  integration and deployment. 

Project description and goals

PDF2.0 had been implemented by CIRV-HDV and CIRV-SDV project which are mainly using the related data for validation functions. But actually, it also includes more about NFV planning, network  design&configuration, vim and storage integration data.  All of the requirements are defined and update in CNTT-RI specification. This project targets on implementation of PDF definition, currently based on SDV,HDV implementation requirements. We plan to generate two types of format, flat and hierarchy.


Definition

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

PDF Specification To implementation  


Implementation

There's no limitation on how to implement PDF, 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 group data entries by the same properties.

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



  • No labels