Descriptor

Model

The following tables summarize an example ASD describing a simple containerized application that is deployed by two Helm Charts.

Example mapping to YAML

For the purpose of illustration of the ASD model, this example uses a YAML mapping of the descriptor model.

sample-app-asd.yaml

The deployment order parameters “deploymentItems” above, the “sampleapp-db-operator” chart will be deployed first, followed by the “sampleapp-services” chart, since they are labelled for consecutive deployment orders. If both charts were to be deployed in parallel, the value of deploymentOrder would be set to 1.

Example of Helm charts:

editor note: placeholder for helm charts

• sampleapp-db-operator-helm.tgz

• sampleapp-services-helm.tgz

ASD Application Package

For illustration purpose, this example shows CSAR package without TOSCA-Metadata directory and ASD is not based on TOSCA language or service template.

ASD yaml file at the root of the archive as the CSAR Entry-definition file example:

MyCompanyASD.yaml file:

In this example, “asd_definitions” is introduced as a new key name to metadata.  Thus, it will be required to be either define or register with either ETSI NFV SOL004 or with OASIS TOSCA TC.

Below figure is an example of CSAR including the ASD (sample-app-asd.yaml), a main TOSCA definition YAML file metadata only (MyCompanyASD.yaml), signature file, manifest, certificate, deployment artifacts, and images.

The two referenced deployment artifacts are contained in the “deployment_artifacts” directory, and the package also contains two container images in OCI format, in the “images” directory.

The corresponding manifest file:

sample-app.mf

Example processing flow of an ASD

The following figure and sequence of steps are to aid the discussion and help derive the requirements.  This simple use case focus on placement.

Open

The figure above gives an illustration of a possible processing flow inside the orchestrator for an ASD-enabled package.

The sequencing steps are:

1. Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.

2. Store relevant information in repo – for internal organization and making the package available for deployment.

3. Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.

4. Fetch descriptors from package.

5. Using received parameters and default values already in the chart to construct the value files. With this input Helm performs a chart render, i,e. translates the charts into concrete K8S resources descriptions.

6. In the placement use case, the concrete K8S workload description (pod, daemonset, deployment, replicaset, statefulset, job, cronjobs, etc) and the ASD will be used by internal logic of orchestrator for placement decision.

7. Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster in the selected O-Cloud.

8. Use Helm to install the application on a particular cluster with the values constructed in step 5.

Requirements:

1. Orchestrator shall support the capability to use the deployment parameters from ASD for the application or CNF deployment. These deployment parameter values shall correspond to the parameters defined in the “lifecycleParameters” section(s) of the ASD.

2. Orchestrator shall support the capability to construct a values file from instance specific parameter values provided at deployment time, and default values supplied in the chart.

3. Orchestrator shall support the capability to perform a chart render into concrete K8S resource descriptions.

4. Container resource management for determining placement for CNF application on certain K8S cluster(s), orchestrator shall support the capability to parse the workload descriptors and extract those values.

Revision History:

July 26,2021: initial draft

July 28,2021: editorial clean fixing example snipped code format