The scope of this page is to maintain the approved list of ONAP specific non-MANO artifact set identifiers. This page is required to be long-live.
The ONAP TSC is the organization that owns the non-MANO artifacts set. The ONAP official contact is onap-tsc@lists.onap.org
The editing of this page is limited to Michela Bevilacqua and Andrei Kojukhov
GENERAL
According to ETSI SOL004 v.2.5.1, every non-MANO artifact set shall be identified by a non-MANO artifact set identifier (TAG) which shall be registered in the ETSI registry.
ETSI registry of non MANO artifact set identifier is available in ETSI wiki https://nfvwiki.etsi.org/index.php?title=Non_MANO_artifact_sets.
Set identifiers can be public or private. ONAP as a public community initiative decided to introduce a set of public identifiers.
Non-MANO artifact sets shall be declared in the manifest file. If the package contains at least one non-MANO artifact set, an entry named "non_mano_artifact_sets:" shall be present in the manifest file on its own line after the "metadata" section.
All files belonging to the same non MANO artifact set shall share a common path prefix (e.g. multiple yang module files will share the same set identifiers).
ONAP PUBLIC NON-MANO ARTIFACTS SET APPROVED by ONAP TSC for REGISTRATION in ETSI
The following table contains the public non-MANO artifact set identifiers which can be used in a PNF/VNF onboarding package per ONAP releases. The relevant examples of using the artifact tags are following the table
| ONAP Release where the artifact ID is initially introduced | Non-MANO artifact ID | Description | Reference ( R-146092 ) (“The published version link shall be updated after Frankfurt release”) | Notes |
|---|---|---|---|---|
| Dublin | onap_ves_events | contains VES registration files for handling external events | The latest requirements: | See the below example and clarifications in 5G - FM Meta Data / 5G - PM Dictionary |
| onap_pm_dictionary | contains the PM dictionary files used for Performance Management | The latest requirements: | See the usage in 5G - FM Meta Data / 5G - PM Dictionary | |
| onap_yang_modules | contains Yang module files for configurations | The latest requirements: | See the usage in 5G - Configuration with NETCONF | |
| onap_ansible_playbooks | contains any ansible playbooks | The latest requirements: | See the usage in 5G - PNF Software Update | |
| onap_others | contains any other non_MANO artifacts, e.g. informational documents | none | See about its usage in 5G - PNF Pre-Onboarding & Onboarding | |
| Frankfurt | onap_pnf_sw_information | PNF software version | The latest requirements: | See about its usage in |
EXAMPLES:
Example 1 (Dublin Release)
In the picture below, an example of a PNF onboarding package including a manifest file with URI's for non-MANO artifacts used in Dublin
NOTES about the example: Folder/file name MANDATORY according to SOL004:
- TOSCA-Metadata directory and TOSCA.meta file (unique CSAR package structure supported in ONAP Dublin)
- Manifest file extension, XXX.mf, located at the root or in a location identified in the .meta file. The name of the file is the same of the TOSCA yaml file
Ín the example the following files are not provided:
- ChangeLog.txt, a human readable text file at the root or in a location identified in the .meta file. (NOT PROVIDED IN THE EXAMPLE )
- xNF testing procedure, NOT mandatory files according to ETSI
- 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 )
- certification files as they could differ according to the type of security option provided by the vendor (NOT PROVIDED IN THE EXAMPLE )
A reference PNF CSAR PACKAGE as example is available dummyPnfv2.csar to review directories structure and new .meta and .mf files format.
NOTES about the Dummy PNF CSAR PACKAGE example:
1) Only csar package structure with TOSCA-Metadata directory will be supported in Dublin timeframe
2) PM Dictionary, Event registration and Yang modules are the only NON MANO ARTIFACTS that will be listed in the manifest file
3) Multiple yang-module files the manifest file and in the dummy package with the intent to demonstrate that multiple files can be assosicated to a single keyword (according to ETSI SOL004)
4) Example package above does not include any certification file or other security options.
Example 2 (Frankfurt Release)
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
A reference PNF CSAR PACKAGE as example is available dummyPnfv3.csar (TBD) to review directories structure and new .meta and .mf files format.
5 Comments
Fei Zhang
Hi, Andrei Kojukhov
Based on latest ONAP TSC meeting , the new proposed non-MANO artifiact identifier (onap_pnf_sw_information) is approved.
So, next step to register it into ETSI. Based on information on the wiki page, there is 'The registration process including creation of the registration template is described in the ETSI wiki https://nfvwiki.etsi.org/index.php?title=Non_MANO_artifact_sets.'
So, my question is 'from ONAP point of view, will you help to register new idenfitier(onap_pnf_sw_information)' on ETSI? Or I can register it by myself?
BR
Fei
Andrei Kojukhov
Hi Fei,
I believe firstly the above table should be extended to Frankfurt release and the approved tag should be described with the reference to the wiki that clarify its use. I expect Michela would do so as one of the owners of this page.
Second, I will create/extend an existing registration form and add the new tag so your colleagues in ETSI NFV would help me to promote the registration of this tag in ETSI.
Andrei
Fei Zhang
Thanks for your clarification, Andrei.
I shall feedback to you with my colleagues name asap.
BestRegards
Fei
Andrei Kojukhov
I suspect this is Arturo Martin De Nicolas.
Fei Zhang
yes, I got confirmation with him. You shall get support from him and I -