Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

editor note: placeholder for helm chartcharts

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

...

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

...

  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