AP: Is CMCC going to test Onboarding Package for VNF in ElAlto ? Can we extend the onboarding package support to VNF ? (Jira ticket ?)
The scope of this page is to define the Onboarding package for a PNF as well as non-MANO artifact specification to be registered with ETSI on ONAP Frankfurt Release. The updated information is marked as light blue comparing to R4 Dublin Release.
...
New in Frankfurt Release for OnBoarding PNF package.
- New noA new non-MANO artifacts artifact for PNF Software version is proposed and discussed on the ONAP R4 Resource IM Call 2019-6-17 AND get the following agreement 'The option 1 is preferred in Frankfurt Release and going for a poll on modeling subcommittee call' (details will be described in this page).
CSAR structure
TOSCA YAML CSAR file is an archive file using the ZIP file format. Two CSAR structures are defined in ETSI SOL004.
...
Option 1) is the unique option supported in ONAP in from Dublin.
META FILE AND MANIFEST FILE
...
2) identify the path of the NON ETSI MANO artifacts (as defined in ETSI SOL004), by the .mf file.
NON ETSI MANO ARTIFACTS
...
Non ETSI MANO artifacts in the onbarding package are provided by the vendor. They provide information that may enable additional functionalities in ONAP.
All the artifacts are optional in the onboarding package.
In Dublin and El Alto following NON ETSI MANO artifacts are supported in ONAP:
1) VES dictionary
2) PM dictionary
3) YANG module files
4) Ansible files
5) information documents provided in the onap_others set identifier
In Frankfurt, following NON ETSI MANO artifacts is are expected to be supported at least:in ONAP
1) VES dictionary
2) PM dictionary
3) YANG module files.
4) PNF Software Version Ansible files
5) information documents
6) PNF information file
According to ETSI SOL004, every non-MANO artifact set shall be identified by a non-MANO artifact set identifier (TAG) which shall be registered in the ETSI registry.
...
onap_ves_events: contains VES registration files
onap_pm_dictionary: contains the PM dictionary files
onap_yang_modules: contains Yang module files for configurations (file names are not defined in ONAP)
onap_ansible_playbooks: contains any ansible_playbooksplaybooks (file names are not defined in ONAP)
onap_scripts: contains any scripts, e.g. installation scripts (NOT REQUIRED IN DUBLIN TIMEFRAME BUT MAY BE REGISTERED LATER)onap_others: contains any other non_MANO artifacts, e.g. informational documents
- onap_nf_information: contains NF(Network Function) related information. e.g. PNF, VNF or xNF itself information. In Frankfurt, it contains PNF Software Version filea new file for PNF information
FILE DIRECTORY
onap_nf_information
pnf_sw_version file
vnf_info....
Two options:
1) we define a single onap nf info directory with different files (i.e pnf specific info, vnf specific info, xnf specific info)
2) we define one directory for each file
FILE NAME
PNF_information ?
FILE FORMAT
The file is a yml file
{
pnf_sw_version: type
}
an example. of the file attached (PNF infor file).......
NEXT STEPS IN FRANKFURT TIMEFRAME
1) In FRANKFURT timeframe SDC is going to implement the PNF package onboarding in line with the agreed non-MANO artifact set identifiers. (JIRA TICKET
2) Register the NON-MANO artifact set identifiers in ETSI and update the reference ONAP page (add the reference)
3) Document the ONAP non-MANO artifact set identifiers in the VNF RQT as new ONAP requirements.
4) Maintain the ONAP non-MANO artifact set identifiers by a ONAP projects for future evolution (to be discussed if MODCOM or VNFRQT project will maintain the ONAP non mano artifact set identifiers) create a csar package file example aligned to Frankfurt release to be added in this page
PNF ONBOARDING PACKAGE EXAMPLE WITH USING NON-MANO ARTIFACTS in FRANKFURT
In the picture below, an example of a PNF onboarding package including a manifest file with URI's for non-MANO artifacts used in Frankfurt
NOTES about the example: Folder/file name MANDATORY according to SOL004:
...
6) A license term file for the xNF located in a directory named Licences located at the root or in a location identified in the .meta file (NOT PROVIDED IN THE EXAMPLE BELOW)