In order to facilitate compatibility with ETSI, ONAP and other telco standards, the CSAR (NFV SOL 004ed351 or ed421004ed421) packaging format is used with following details:
The structure and format of an O-RAN package shall conform to the TOSCA Simple Profile YAML v1.
...
1 Specification of the CSAR format. The zip file format shall conform to Document Container Format File
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
- ETSI-Entry-Certificate
Non-MANO artifact sets, specified in ETSI NFV SOL004ed431 section 4.3.7
Registered non-MANO artifact keywords 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 new manifest metadata proposed in the following table:
Name | Value | Notes | Qualifier |
application_name | A sequence of UTF-8 characters. | The value shall be identical to those specified in the MainServiceDescriptor, e.g., asdApplicationName in ASD | O |
application_provider | A sequence of UTF-8 characters. | The value shall be identical to those specified in the MainServiceDescriptor, e.g., asdProvider in ASD | O |
release_date_time | A string formatted according to IETF RFC 3339 | Timestamp of the package release time | M |
entry_definition_type | enum[asd] | asd: only ASD is included in the package | M |
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
The following is an example of an ASD onboarding package :
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: