Package Requirements

The ASD onboarding package format is based on the TOSCA CSAR with TOSCA-Metadata directory format, with the following additional:  

• The structure and format of an ASD package shall conform to the TOSCA Simple Profile YAML v1.1 or v1.3 Specification of the CSAR format, as specified in ETSI NFV SOL004ed431 section 4.1.1.

• An ASD package shall contain a main TOSCA definitions YAML file representing all or part of the ASD, and additional files.
• CSAR format with TOSCA-Metadata directory, specified in ETSI NFV SOL004ed431 section 4.1.2, with the differences that the following TOSCA.meta file keynames extensions are optional:
  • ETSI-Entry-Change-Log
  • ETSI-Entry-Tests
  • ETSI-Entry-Licenses

• Support non-MANO artifact sets description in the manifest file, as specified in ETSI NFV-SOL004ed431 clause 4.3.7

• Registered non-MANO artifact keywords (ONAP Non-MANO Artifacts Set Identifiers) can be reused, to avoid duplication

• Package and artifacts security, specified in ETSI NFV SOL004 ed431 section 5 and 4.3.6

• Package manifest file, specified in ETSI NFV SOL004ed431 section 4.3.2, with the exception that table 4.3.2-1 (the valid names and values) is replaced with the following table:

Additional non-mano-artifact keyword

The non-mamo-artifact-set in manifest file is used to onboard any additional NF specific artifacts. There is a need to onboard NF specific artifacts  consumed by rAPP.

The following keywords are defined:

• “onap_vendor_artifacts”: NF specific artifacts consumed by rAPP

• “vendor_name”: global unique id of the artifact provider.

• “artifact_type”: artifact type which shall be unique id  within the artifact provider

• “source”: artifact path/file name.

EXAMPLE:

onap_vendor_artifacts:
   vendor_name: Ericsson
   artifact_type: [rApp_name1]
   source:/artifacts/[rapp_name1]/rapp.zip 
   source:/artifacts/[rapp_name1]/rapp.yml
   vendor_name: Ericsson
   artifact_type: [rApp_name2]
   source:/artifacts/[rapp_name2]/rapp.zip

ASD Package Example

The following is an example of ASD metadata:

metadata:                                                  

  application_name: vCU

  application_provider: Ericsson

  release_date_time: 2021-10-21T11:30:00+05:00

  entry_definition_type: asd

Here is an example of an ASD onboarding package (without package security): asd.csar

The following is an example of an ASD onboarding package with package security in picture:

Image Added

In order to facilitate compatibility with ETSI, ONAP and other telco standards, the CSAR (NFV SOL 004ed351 or ed421) packaging format is used. The only modification is allowing the proposed Application Service Descriptor (ASD) to be a top-level descriptor for the package, instead of an NSD or VNFD as defined in SOL001.

Additionally, the following directories will exist inside the CSAR:

deployment_artifacts: where all deployment files go, like Helm charts.
images: holds container images referenced from the main application and dependencies, in OCI format.(ref: https://github.com/opencontainers/image-spec)

Note that the “images” directory may be empty, or only contain a part of the images required for the whole application. This might happen for example in application update packages, where the container images may have already been onboarded onto the associated registry. In case images are present, they must be referenced in the CSAR manifest.

This application packaging format is designed to support a single, container-based deployment “flavor” or “type”. If an application has multiple such deployment types, there should be multiple packages, with their own appropriate descriptors.

An orchestrator is expected to load any container images present in the package onto the correct registry for the target cluster(s) before attempting to deploy the application. Since the images are in OCI format, they should follow the OCI image layout specification, and MUST contain a “name” annotation in their index.json layout descriptor. This name should be used as the “tag” value when the orchestrator provisions the image in the corresponding registry.

Working/discussion material: