Descriptor

Model

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

Table 1: Application Service Descriptor model

Table 2: “deploymentItems” model

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

kind: ASD

applicationServiceDescriptor:

  id: “fdsa-xdsfg-sdfsd-wqeuy”

  schemaVersion: 1.0

  provider: MyCompany

  applicationName: SampleApp

  applicationVersion: “2.3”

  applicationInfoName: “Sample Application”

  infoDescription: “Sample Application to Illustrate ASD Usage”

  extCpd:

  - webpage-service

  - transactionAPI

  extraServiceRequirements: {}

  enhancedClusterCapabilities: [ o-ran.o-cloud.hw.gpgpu ]

  deploymentItems:

  - itemId: 1

    artifactId: “sampleapp-db-operator-helm.tgz”

    deploymentOrder: 1

    lifecycleParameters:

      [ “.Values.db.fullBackupInterval”, “.Values.db.walConsolidationInterval” ]

  - itemId: 2

    artifactId: “sampleapp-services-helm.tgz”

    deploymentOrder: 2

    lifecycleParameters: [ “.Values.app.initialWebReplicas” ]

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 chart

• sampleapp-db-operator-helm.tgz
• sampleapp-services-helm.tgz

ASD 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:

tosca_definitions_version: tosca_simple_yaml_1_3

metadata:

  template_name: MainServiceTemplate

  template_author: Onboarding portal

  template_version: 1.1

  asd_definitions: Definitions/sample-app-asd.yaml

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.

├── MyCompanyASD.yaml

├── sample-app-asd.yaml

├── sample-app-asd.yaml.sig.cms

├── sample-app.mf

├── sample-app.cert

├── deployment_artifacts

│   ├── sampleapp-db-operator-helm.tgz

│   └── sampleapp-services-helm.tgz

└── images

    ├── containerImageA.oci

    └── containerImageB.oci

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, shows:

metadata:

  asd_name: sample-app-asd.yaml

  asd_provider: MyCompany

  asd_software_version: 2.3

  asd_package_version: 4.0

  asd_application_name: SampleApp

Source: sample-app-asd.yaml

Source: sample-app-asd.yaml.sig.cms

Source: sample-app.mf

Source: sample-app.cert

Source: deployment_artifacts/sampleapp-db-operator-helm.tgz

Source: deployment_artifacts/sampleapp-services-helm.tgz

Source: images/containerImageA.oci

Source: images/containerImageB.oci

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.

Figure 1: Example of possible sequence of operations inside orchestration

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.