ONAP Non-MANO Artifacts Set Identifiers
- Andy Mayer
- Fei Zhang (Ericsson)
- Michela Bevilacqua
- andreik
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 @andreik
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 | 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