Page History

Note: work in progress

Table of Contents

SDC Package Onboarding Process

SDC Epic

• SDC shall support Application Package onboarding and distribution, where the onboarding package conforms to ETSI SOL004 and the embedded model conforms to ASD.

User Story

...

The App Package shall be compliant to the ETSI NFV SOL004 CSAR structure with the TOSCA-Metadata directory

• Supports the ETSI NFV SOL004 version 3.3.1, 2.7.1, 2.6.1 and 2.5.1
• For SDC onboarding, App package requires to have the TOSCA-Metadata directory 
• Create ASD_1_0_types.yaml which represents Application Service Descriptor (ASD) in TOSCA
• introduce the following metadata for App package. By using the new metadata, SDC and orchestrators know this package is for App and based on ASD

...

SDC creates an SDC VSP package thru onboarding of an Application Service CSAR based on ASD

• SDC copies the contents of TOSCA.meta metadata from the onboarding App package TOSCA.meta
• SDC maps ASD to ONAP internal model in SDC VSP
  • Design suggestion: ASD ↔ ONAP VF, DeploymentItems ↔ VF-Modules
• SDC generates the GlobalSubstitutionTypesServiceTemplate.yaml by including the app_main_descripter.mf information
• SDC does not use openecomp-heat directory for the App Package
• SDC generates Artifacts directory by copying artifacts from the onboarding App package
• SDC preserves the original onboarding App package in the Deployment directory
• SDC should be able to handle large-size image files. SDC stores the image files to the Kubernetes Object Storage temporarily and waits for the Runtime Catalog Manager picks up and stores the images files to the Image repository
• SDC preserves the original onboarding TOSCA.meta (rename TOSCA.meta.original) in the TOSCA-Metadata

Concepts

• K8S CISM Cluster: Container Infrastructure Service Manager Cluster performs the same function as VIM Zone but operates on containerized application level.
• CNF: Cloud Native Network Function. Containerized VNF is designed to be deployed in the cloud as a container. CNF is a better fit for microservice architecture due to the deployment size.
• Kubernetes: Kubernetes (K8s) is an open-source system for automating deployment, scaling and management of containerized applications
• POD: A Pod is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.

App Onboarding Package Requirement 

NF Onboarding Package Structure (with ASD only)

The following diagram depicts the NF Onboarding Package Structure with ASD only. 

Note: the package structure is in progress

Image Added

Application Package Onboarding and Distribution to ONAP

The following diagram depicts Application Package onboarding and distribution to ONAP and repositories.

SDC Package Onboarding Process

SDC Epic

• SDC shall support Application Package onboarding and distribution, where the onboarding package conforms to 1) ETSI SOL004, 2) Application onboarding package requirements, and 3) its embedded model conforms to ASD.
• Note: ASD-based vFW could be a candidate, but we are looking for additional NF use cases.

SDC User Story

SDC Onboarding and Distribution Sequence

Vendor App Onboarding Package

Application Onboarding Package conforms to the ETSI SOL004 inspired until SOL004

• 1) makes the SOL001 VNFD optional (to allow ASD and/or APP Descriptor) and
• 2) allow App package-specific metadata

SOL004 Package CSAR Structure

ONAP SDC supports SOL004-conformed CSAR onboarding with the TOSCA-Metadata directory, which includes the TOSCA.meta metadata file, providing and entry information for processing a CSAR file.

• TASK #<1>: The App Package shall be compliant to the ETSI NFV SOL004 CSAR structure with the TOSCA-Metadata directory
  • ONAP SDC supports only the CSAR onboarding with the TOSCA-Metadata directory
• ASSUMPTION: SOL001 VNFD mandatory requirement in the current SOL004 needs to be changed; i.e., make SOL001 VNFD in SOL004 optional. 
  
  • Note: this PoC assumes the SOL001 VNFD is optional in the SOL004 package. Instead, ASD will be embedded in the App package
• Locations of files in CSAR are defined by Tosca.meta, Manifest and main TOSCA definition files

App Package structure that is defined in ETSI NFV SOL004

The following describes a sample App package structure. ETSI SOL004 specified the TOSCA-Metadata directory and TOSCA.meta file locations. Other file locations could be determined as needed.

TASK #<2>: ASD_1_0_types.yaml will represent Application Service Descriptor (ASD) in TOSCA

!----- <MRF>.mf                                      // main manifest file

!------TOSCA-Metadata

!------TOSCA.meta

!------TOSCA.meta.sig.cms

!------Definitions

!----- MRF.yaml.   (main App yaml)

!----- MRF.yaml.sig.cms (signature)

!----- OtherTemplates (e.g. type definitions).    // e.g., ASD_1_0_types.yaml. once ASD types are standardized, we will have a formal name.

|----- OtherTemplates signatures.                       // signature for other templates

!------Artifacts (additional artifacts files)Files 

!----- ChangeLog.txt

!----- ChangeLog.txt.sig.cms

!----- global.cert (global certificate for the package)

!----- image(s)

!----- image(s) signature(s)

!----- other artifacts                               // Deployment > HELM

!----- other artifacts signatures

!------Tests

!----- file(s)

!----- signature(s)

!------Licenses

!----- file(s)

!----- signature(s)

!------Scripts

!----- install.sh

!----- install.sh.sig.cms

App Package Directory and File Details

• <MRF>.mf : It is the main manifest file for the Application package, which contains
  • metadata list
  • list of all files
  • non-MANO-artifacts list: contains locations of non-MANO-artifacts 

• • TASK #<3>: The App package shall introduce the following metadata to define the package type/model.
  • TASK #<4>: SDC shall detect the oran_entry_defintion_type="asd" metadata and process the Application package onboarding path.
    • oran_application_name
    • oran_application_provider
    • oran_release_date_time
    • oran_entry_definition_type.   [ "asd" ]

• • • e.g., app_main_descripter.mf

metadata:

oran_application_name: vCU

oran_application_provider: Ericsson

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

oran_entry_definition_type: asd

• • Define Source paths: 
    • Source: ChangeLog
    • Source: Definitions/main_app_template.yaml
    • Source: Definitions/oran_asd_types.yaml
    • Source: Definitions/oran_asd_types.sig.cms
    • Source: Images
    • Source: Artifacts
    • Source: LcmScripts
    • Source: License
    • Source: TOSCA-Metadata

• TOSCA-Metadata directory: It contains the entry points:

<ETSI keynames extension>

note: for ASD, we don't need to use all the following entries. SDC does not copy most of the keynames, except ETSI-Entry-Manifest for validation.

note: in ETSI NFV, making the ETSI-Entry-Lincense optional is under discussion.

• • TOSCA.meta
    • TASK #<5>: for ASD, SDC use the same metadata structure defined by TOSCA and SOL004, plus use only ETSI-Entry-Manifest from the above list
      • TOSCA-Meta-File-Version
      • CSAR-Version
      • Created-By
      • Entry-Definitions

• • • • ETSI-Entry-Manifest

e.g.,

TOSCA-Meta-File-Version: 1.0

CSAR-Version: 1.1

Created-By: vendorA

Entry-Definitions: Definitions/main_app_template.yaml

ETSI-Entry-Manifest: app_main_descripter.mf

• Definitions
  
  • asd_types.yaml                        // TASK #<6>: define ASD data models for node_types, artifact_types, data_types...

   // note: it will be finalized after the ASD data model 

tosca_definitions_version: tosca_simple_yaml_1_3


data_types:
  ExtCpdData:
    version: 1.0
    description: "Describes the datatype for exposed service"
    properties:
      id:
        description: "A symbolic name for this exposed service (extCpd)"
        required: true
        type: string
      virtualLinkRequirement: 
        description: >
          Refers in an abstract way to the network or multiple networks that 
          the ExtCpd shall be exposed on (ex: OAM, EndUser, backhaul, LI, etc)
        required: false
        type: string
      interfaceOrder:
        description: >
          Mandatory attribute for a secondary network interface. 
          Defines the order (0-N) in which an the additional/secondary 
          network interface declaration appears in the pod manifest
        required: false        
      networkInterfaceRequirements:
        description: >
          Details container implementation specific requirements on 
          the NetworkAttachmentDefinition
        required: false
        type: ExtCpdData.NetworkInterfaceRequirementsIE
      switchPlane:
        description: >
          Used to indicate resource pool (left or right) to allocate 
          connection resources for sepcific secondary interfaces
        required: false
        type: string
        constraints:
          - valid_values: [left, right]
      inputParamMappings:
        description: >
          Information on what helm chart input parameters that 
          are required to be configured for this extCpd
        required: false
        type: ExtCpdData.ParamMappings
      resourceMapping:
        description: >
          Kubernetes API resource name for the resource manifest for the service
        required: false
        type: ExtCpdData.ParamMappings
    

artifact_types:
  AsdDeploymentItem:
    version: 1.0
    description: "The default type of the ASD artifacts"
    properties:
      artifactType:
        type: string
        constraints:
          - valid_values: ["helm_chart", "helmfile", "crd", "terraform" ]
      itemId:
        type: integer
      deploymentOrder:
        type: integer
      lifecycleParameters:
        type: list
        entry_schema: string

    
node_types:
  ApplicationServiceDescriptor:
    description: "The ASD node type"
    properties:
      id: 
        type: string
      provider:
        type: string
      applicationName:
        type: string
      applicationVersion:
        type: string
      extCpds: 
        type: list
        entry_schema: ExtCpdData
      enhancedClusterCapabilities:
        type: list
        entry_schema: string       
    requirements:
      - virtual_link_1: 
          capability: tosca.capabilities.nfv.VirtualLinkable 
          relationship: tosca.relationships.nfv.VirtualLinksTo 
          occurrences: [ 0, 1 ] 
      - virtual_link_2: 
          capability: tosca.capabilities.nfv.VirtualLinkable 
          relationship: tosca.relationships.nfv.VirtualLinksTo 
          occurrences: [ 0, 1 ]
      - ...
      - virtual_link_8: 
          capability: tosca.capabilities.nfv.VirtualLinkable 
          relationship: tosca.relationships.nfv.VirtualLinksTo 
          occurrences: [ 0, 1 ]    
        

• • main_app_template.yaml.               // descriptor leveraging ASD

e.g., Sample main_app_template.yaml

tosca_definitions_version: tosca_simple_yaml_1_3
imports:
  - asd_types.yaml
  - nsd_types.yaml

topology_template:
  substitution_mappings: 
    node_type: tosca.nodes.nfv.ASD_in_NS
    substitution_filter:
      properties:
        - descriptor_id: { equal: 'b1bb0ce7-2222-4fa7-95ed-4840d70a1179' }
    requirements: 
      virtual_link_1: [ applicationServiceDescriptor, virtual_link_1 ]
      virtual_link_2: [ applicationServiceDescriptor, virtual_link_2 ]
      ...
      virtual_link_8: [ applicationServiceDescriptor, virtual_link_8 ]    

  
  node_templates: 
    applicationServiceDescriptor:
      type: ApplicationServiceDescriptor
      version: 1.0
      description: "Sample Application to Illustrate ASD Usage"
      properties: 
        id: fdsa-xdsfg-sdfsd-wqeuy
        provider: MyCompany
        applicationName: SampleApp
        applicationVersion: “2.3”
        applicationInfoName: “Sample Application”
        extCpds:
          - id: webpage-service
            virtualLinkRequirement: endUser  
          - id: transactionAPI
            virtualLinkRequirement: backhaul
            interfaceOrder: 0
            switchPlane: left
        enhancedClusterCapabilities: [ o-ran.o-cloud.hw.gpgpu ]
      artifacts: #these are the deployment items:
        sampleapp-db:
          type: AsdDeploymentItem
          file: "sampleapp-db-operator-helm.tgz" # this can be also a uri
          properties:
            artifactType: "helm_chart" 
            itemId: 1 
            deploymentOrder: 1 
            lifecycleParameters: 
              - ".Values.db.fullBackupInterval"
              - ".Values.db.walConsolidationInterval"
        sampleapp-services:
          type: AsdDeploymentItem
          file: "sampleapp-services-helm.tgz"  # this can be also a uri
          properties:
            artifactType: "helm_chart"
            itemId: 2 
            deploymentOrder: 2 
            lifecycleParameters:
              - ".Values.app.initialWebReplicas"

...

SDC creates AS internal CSAR (VF resource) by importing VSP CSAR to add CNF/Application based on ASD

• SDC generates TOSCA-Metadata directory and TOSCA.meta for ASD package
• SDC maps the onboarding ASD models into the ONAP internal model
• SDC generates resource-<...>-template and template-interface models based on the onboarding ASD model
• SDC preserves the original onboarding App package and adds additional License files thru SDC UI
• SDC UI should be able to modify some of ASD property values
  • SDC UI populates lifecycleManagement values as needed
• If values.schema.json files exist, SDC UI validates values.yaml files and populate customizable values

...

Create an Service CSAR consists of one or more CNF/Application based on ASD

• SDC generates TOSCA-Metadata directory and TOSCA.meta
• SDC maps the onboarding ASD models into the ONAP internal models
• SDC uses the "HELM" directory under the Artifacts to contain Helm Charts

...

SDC distributes Service CSAR to ONAP runtime components thru DMaaP

• Assuming no SDC impact for this 

...

For the App Package notification, ONAP Runtime Catalog Manager queries from SDC and stores associated Helm Charts and Images to the target Helm and Image Artifact Repositories

• Get Helm Charts from the Helm directory and stores the target Helm Artifact Repository
• Get Images from the Object Storage and stores the target Image Artifact Repository

SDC Onboarding and Distribution Sequence

Vendor App Package

Application Service Package conforms to ETSI SOL004 (inspired) until SOL004

• 1) makes the SOL001 VNFD optional and
• 2) allow App package-specific metadata

SOL004 Package CSAR Structure

ONAP SDC supports SOL004-conformed CSAR onboarding with the TOSCA-Metadata directory, which includes the TOSCA.meta metadata file, providing and entry information for processing a CSAR file.

• TASK #<1>: The App Package shall be compliant to the ETSI NFV SOL004 CSAR structure with the TOSCA-Metadata directory
  • ONAP SDC supports only the CSAR onboarding with the TOSCA-Metadata directory
• SOL001 VNFD mandatory requirement in the current SOL004 needs to be changed; i.e., make SOL001 VNFD in SOL004 optional. 
  
  • Note: this PoC assumes the SOL001 VNFD is optional in the SOL004 package. Instead, ASD will be embedded in the App package
• Locations of files in CSAR are defined by Tosca.meta, Manifest and main TOSCA definition files

App Package structure that is defined in ETSI NFV SOL004

The following describes a sample App package structure. ETSI SOL004 specified the TOSCA-Metadata directory and TOSCA.meta file locations. Other file locations could be determined as needed.

TASK #<2>: ASD_1_0_types.yaml will represent Application Service Descriptor (ASD) in TOSCA

!----- <MRF>.mf                                      // main manifest file

!------TOSCA-Metadata

!------TOSCA.meta

!------TOSCA.meta.sig.cms

!------Definitions

!----- MRF.yaml.   (main App yaml)

!----- MRF.yaml.sig.cms (signature)

!----- OtherTemplates (e.g. type definitions).    // e.g., ASD_1_0_types.yaml. once ASD types are standardized, we will have a formal name.

|----- OtherTemplates signatures.                       // signature for other templates

!------Artifacts (additional artifacts files)Files 

!----- ChangeLog.txt

!----- ChangeLog.txt.sig.cms

!----- global.cert (global certificate for the package)

!----- image(s)

!----- image(s) signature(s)

!----- other artifacts

!----- other artifacts signatures

!------Tests

!----- file(s)

!----- signature(s)

!------Licenses

!----- file(s)

!----- signature(s)

!------Scripts

!----- install.sh

!----- install.sh.sig.cms

App Package Directory and File Details

• <MRF>.mf : It is the main manifest file for the Application package, which contains
  • metadata list
  • list of all files
  • non-MANO-artifacts list: contains locations of non-MANO-artifacts 

• • TASK #<3>: The App package shall introduce the following metadata to define the package type/model.
  • TASK #<4>: SDC shall detect the oran_entry_defintion_type="asd" metadata and process the Application package onboarding path.
    
    • app_id.                                         
    • app_provider_id
    • app_product_name
    • app_release_date_time
    • app_software_version                
    • app_package_version
    • oran_id
    • oran_product_name
    • oran_provider_id
    • oran_package_version
    • oran_release_date_time
    • oran_entry_definition_type.   [ "asd", "app", "app-asd", ... ]

• • • e.g., app_main_descripter.mf

metadata:

asd_id:  2116fd24-83f2-416b-bf3c-ca1964793bcf

app_provider_id: <vendorA>

app_product_name: vFW

app_release_date_time: 2021-10-18T10:00:00+03:00

app_software_version: 1.0.0

app_package_version: 1.0

oran_id: 2116fd24-83f2-416b-bf3c-ca1964793bcf

oran_product_name: vFW

oran_provider_id: vendorA

oran_package_version: 1.0

oran_release_date_time: 2021-10-18T10:00:00+03:00

oran_entry_definition_type: asd

• • Define Source paths: 
    • Source: ChangeLog
    • Source: Definitions/main_app_template.yaml
    • Source: Definitions/oran_asd_types.yaml
    • Source: Definitions/oran_asd_types.sig.cms
    • Source: Images
    • Source: Artifacts
    • Source: LcmScripts
    • Source: License
    • Source: TOSCA-Metadata

• TOSCA-Metadata directory: It contains the entry points:

<ETSI keynames extension>

note: for ASD, we don't need to use all the following entries. SDC does not copy most of the keynames, except ETSI-Entry-Manifest for validation.

note: in ETSI NFV, making the ETSI-Entry-Lincense optional is under discussion.

Image Removed

• • TOSCA.meta
    • TASK #<4>: for ASD, SDC use the same metadata structure defined by TOSCA and SOL004, plus use only ETSI-Entry-Manifest from the above list
      • TOSCA-Meta-File-Version
      • CSAR-Version
      • Created-By
      • Entry-Definitions

plus

• • • • ETSI-Entry-Manifest

e.g.,

TOSCA-Meta-File-Version: 1.0

CSAR-Version: 1.1

Created-By: vendorA

Entry-Definitions: Definitions/main_app_template.yaml

ETSI-Entry-Manifest: app_main_descripter.mf

ETSI-Entry-Change-Log: ChangeLog.txt

• Definitions
  
  • ASD_1_0_types.yaml                        // TASK #<>: define ASD data models for node_types, artifact_types, data_types...

   // note: it will be finalized after the ASD data model 

• • main_app_template.yaml.               // descriptor leveraging ASD

e.g., Sample main_app_template.App

Image Removed

• Artifacts(optional; Images, Licenses and Artifacts directories can be located under the root directory)
  • Images
    • <image>          // or image reference
    • <image>           // or image reference
  • Licenses
    • LICENSE.txt

  • 
    

    Deployment

    • HELM             //TASK #<5>#<7>: use the "HELM" directory to contain Helm Charts
      • <Helm Chart A file>                                  // Helm Charts can include values.schema.json along with values.yaml
      • <Helm Chart B file>                                  // It is for imposing a structure on the values.yaml file

                                                                                                              // TASK #<6>#<8>: If values.schema.json files exist, SDC UI uses them to validate values.yaml files and populates customizable values

...

• TOSCA-Metadata
  • TOSCA.meta:
    • It is generated by SDC, and SDC copies the following metadata and drops other custom metadata 
    • TASK #<7>#<9>: SDC shall copy the new oran-<> metadata (asd)  entries from the onboarding App package manifest (.mf) and put them on the main TOSCA definition file metadata.

...

• • main_app_template.yaml.                                                // TASK #<>#<10>: SDC copies the asd manifest entries to this main TOSCA definition file
  • GlobalSubstitutionTypesServiceTemplate.yaml.            // TASK #<8>#<11>: SDC generates this based on the onboarding descriptors and metadata

note: The following definitions files are there for all VSPs, but not really used outside of SDC; i.g., The VSP itself is an internal SDC structure, and I believe it is not supposed to be read/used outside of SDC.

For ASD, there would be no impact.

• •  onap (TBD)
    • _index.yml
    • artifacts.yml
    • capabilities.yml
    • data.yml
    • interfaces.yml
    • nodes.yml
    • relationships.yml
  • onapecomp                                
    
    • _index.yml
    • artifacts.yml
    • capabilities.yml
    • data.yml
    • interfaces.yml
    • nodes.yml
    • relationships.yml
  • openecomp-heat                      
    • _index.yml
    • data.yml
    • groups.yml
    • nodes.yml
  •  tosca
    • _index.yml
    • artifacts.yml
    • capabilities.yml
    • data.yml
    • groups.yml
    • interfaces.yml
    • nodes.yml
    • policies.yml
    • relationships.yml
• Artifacts: TASK #<10>#<12>: SDC generates this directory by copying artifacts from the onboarding App package
  
  • <cnf>.mf                   // TASK #<>#<13>: based on the app/asd metadata in the onboarding manifest file, SDC creates app/asd-specific metadata (e.g., subcategory: ASD)

// note: We can define a specific category for ASD package types, which the Resource created based on this VSP (Import VSP feature) will be associated with.

// The category associated will be defined in the main TOSCA descriptor metadata. So, runtime components solutions could know what type of resource they are dealing with.

• • Definitions
  ASD_1
  • • • asd_
  0_
  • • • types.yaml
      • <main_app_template>.yaml
    • Deployment: TASK
  #<11>
  • • #<14>: SDC preserves the original onboarding App package 
    APP
    • • • ORAN_
    PACKAGE.
    • • • PACKAGE             
     
    • • • //
    copy of
    • • • a directory where the original
    AS
    • • • package is stored
      • Images: TASK
    #<12>
    • • #<15>: SDC should be able to handle large-size image files. SDC stores the image files to the Kubernetes Object Storage temporarily and waits for the Runtime Catalog Manager picks up and stores the images files to the Image repository.  
        • <image>
        • <image>
      • HELM (TBD)
        • <helm file>
        • <helm file>
      •  Informational
        • <Guide>
          • VSP_<?>_Information.txt
      • LcmScripts
        • <scripts>
      • Licenses
        • LICENSE.txt
      • TOSCA-Metadata: TASK
    #<13>
    • • #<16>: SDC preserves the original onboarding TOSCA.metadata
        • TOSCA.meta.original
      • ChangeLog.txt
      • vendor-license-model.xml (not sure how SO uses)
      • vf-license-model.xml (not sure how SO uses)

    
    

    Create VF CSAR file - an original way (most likely, this is the

    ...

    option for PoC)

    • TOSCA-Metadata: TASK #<14>#<17>: SDC generates TOSCA-Metadata directory and TOSCA.meta based on the corresponding VSP
      • TOSCA.meta
    • Definitions: TASK #<15>#<18>: SDC maps the onboarding ASD models into the ONAP internal. See the mapping section betlow.below.

    note: all necessary TOSCA types needs to be included as part of the ONAP TOSCA model. So they will all be included in those files, classified based on the type added. 

    • • artifacts.yml
      • capabilities.yml
      • data.yml                 // TASK
    #<>
    • • #<19>: SDC extends data.yml for ASD types
      • groups.yml.            // TASK
    #<>
    • • #<20>: SDC extends the VF-Module for additional properties
      • interfaces.yml
      • nodes.yml               // TASK
    #<>
    • • #<21>: SDC extends nodes.yml for ASD-based CNF
      • policies.yml
      • relationships.yml
      • resource-<...>-template.yml. TASK
    #<16>
    • • #<22>: SDC generates this based on the onboarding ASD model
        • resource-<...>-template-interface.yml TASK
    #<17>
    • • • #<23>: SDC generates this based on the onboarding ASD model
    • Artifacts
      • Deployment: TASK #<18>#<24>: SDC preserves the original onboarding App package and additional License files thru SDC UI
        • ASORAN_PACKAGE (original)
          • <App>.csar           // original vendor CSAR
        • VENDOR_LICENSE
        • VF_LICENSE
        • HELM
          • <HELM Chart A file>
          • <HLEM Chart B file>
        • IMAGE
          • <image>
          • <image> 
        •  Informational
        • OTHER
          • VSP_<?>_Information.txt
    • csar.meta
    • Files. (missing from SDC****; Its handling is under discussion)
      • Images
        • <image>
        • <image>
    • e.g.,

    tosca_definitions_version: tosca_simple_yaml_1_3
    metadata:
      invariantUUID: 92e593ad-cc7d-4a97-8b64-83bc301e2e4f
      UUID: 90c7b63b-001a-4398-abb9-951e1a842437
      name: asd1
      description: f
      category: Generic
      type: VF
      subcategory: ASDApplication Service Descriptor           // TASK #<>#<25>: SDC extends the subcategory to have ASDApplication Service Descriptor;    was  Network Elements
      resourceVendor: d
      resourceVendorRelease: 2.6.1
      reourceVendorModelNumber: ''
    imports:
    - nodes:
        file: nodes.yml
    - datatypes:
        file: data.yml
    - capabilities:
        file: capabilities.yml
    - relationships:
        file: relationships.yml
    - groups:
        file: groups.yml
    - policies:
        file: policies.yml
    - annotations:
        file: annotations.yml
    - resource-asd1-interface:
        file: resource-Asd1-template-interface.yml
    topology_template:
      inputs:
        skip_post_instantiation_configuration:
          default: true
          type: boolean
          required: false
        nf_naming:
          default:
            ecomp_generated_naming: true
          type: org.openecomp.datatypes.Naming
          required: false
        multi_stage_design:
          default: false
          type: boolean
          required: false
        nf_naming_code:
          type: string
          required: false
        nf_function:
          type: string
          required: false
        controller_actor:
          default: SO-REF-DATA
          type: string
          required: false
        availability_zone_max_count:
          default: 1
          type: integer
          required: false
        sdnc_artifact_name:
          type: string
          required: false
        max_instances:
          type: integer
          required: false
        nf_type:
          type: string
          required: false
        sdnc_model_version:
          type: string
          required: false
        nf_role:
          type: string
          required: false
        min_instances:
          type: integer
          required: false
        sdnc_model_name:
          type: string
          required: false
      node_templates:
        asd_instance:
          type: org.onap.asd.CNF
          metadata:
            invariantUUID: 3948bd3d-f4e2-41a9-b3b4-edc6c6db927e
            UUID: 05329593-52f8-482d-a967-8dbb28bb117a
            name: Asd1.CNF
            description: Not reusable inner VFC
            category: Generic
            version: '1.0'
            customizationUUID: 59c10655-f68e-47d3-bf7b-d8f5698f6f75
            type: VFC. // ??
            subcategory: Abstract
            resourceVendor: d
            resourceVendorRelease: 2.6.1
            reourceVendorModelNumber: ''
          properties:
            oran_id: ASD Instance

            properties oran_product_name: vFW

            asdoran_provider_id: ASD InstancevendorA

            ascoran_schemapackage_version: 1.0.0
      group:
        Asd..helmA..module-0:
          type: org.openecomp.groups.VfModule
          metadata:
            vfModuleModelName: Asd..helmA..module-0
            vfModuleModelInvariantUUID: 766017db-5c11-47f9-a3c4-1fed0dbae9cb
            vfModuleModelUUID: 57a35aad-4290-4b55-a0b2-150aad6da058
            vfModuleModelVersion: '0.0'
          properties:
            min_vf_module_instances: 1
            vf_module_label: helmA
            max_vf_module_instances: 1
            vf_module_type: Base
            isBase: true
            initial_count: 1
            volume_group: false
        Asd..helmB..module-1:
          type: org.openecomp.groups.VfModule
          metadata:
            vfModuleModelName: Asd..helmB..module-0
            vfModuleModelInvariantUUID: 766017db-5c11-47f9-a3c4-1fed0dbae9cb
            vfModuleModelUUID: 57a35aad-4290-4b55-a0b2-150aad6da058
            vfModuleModelVersion: '0.0'
          properties:
            min_vf_module_instances: 0
            vf_module_label: helmB
            vf_module_type: Expansion
            isBase: false
            initial_count: 0
            volume_group: false
      substitution_mappings:
        node_type: org.openecomp.resource.vf.Asd1
        properties:
          nf_naming:
          - nf_naming
          skip_post_instantiation_configuration:
          - skip_post_instantiation_configuration
          multi_stage_design:
          - multi_stage_design
          nf_function:
          - nf_function
          nf_naming_code:
          - nf_naming_code
          controller_actor:
          - controller_actor
          availability_zone_max_count:
          - availability_zone_max_count
          sdnc_artifact_name:
          - sdnc_artifact_name
          max_instances:
          - max_instances
          nf_type:
          - nf_type
          sdnc_model_version:
          - sdnc_model_version
          nf_role:
          - nf_role
          min_instances:
          - min_instances
          sdnc_model_name:
          - sdnc_model_name

    
    

    
    

    Create VF CSAR file thru the SDC Multi Model Way

    ...

    (it is under evaluation for ASD)  

    • TOSCA-Metadata
      • TOSCA.meta TASK #<19>#<26>: SDC generates TOSCA-Metadata directory and TOSCA.meta
    • Definitions: TASK #<20>#<27>: for the Multi Model way, SDC does not use ONAP internal model. Note: impact to the existing ONAP components are under discussion.
    •  
      • artifacts.yml
      • capabilities.yml
      • data.yml
      • groups.yml
      • interfaces.yml
      • nodes.yml
      • policies.yml
      • relationships.yml
      • asd_types.yaml.                            // instead of using ONAP type definitions, support the ASD model specific definitions are included
      • resource-<...>-template.yml.       // TASK #<21>#<28>: SDC UI modifies onboarding ASD for changing the default values
      • resource-<...>-template-interface.yml.  // TASK #<22>#<29>: SDC UI modifies onboarding ASD for changing the default values.
    • Artifacts
      • Deployment
        • ASORAN_PACKAGE
          • AS_<...>DataTypes.csar
        • HELM
          • <HELM Chart file>
          • <HLEM Chart file>
        • IMAGE
          • <image>
          • <image>
        •  VENDOR_LICENSE
          • vendor-license-model.xml

    ...

    • Node type for ASD and data type for the deployment items added to Definitions/nodes.yaml and Definitions/data.yaml respectively
    • interface type (i.e. the substitution mapping type) created from org.openecomp.resource.abstract.nodes.VF, in standard ONAP way, with the standard ONAP properties
    • Main template generated as follows: 
      • node template added for the ASD type generated from the definition in the onboarded csar
      • vfModule group type added for each deployment item. see below for explanation of the properties and values used
      • extend the org.openecomp.groups.VfModule to hold the DeploymentItems properties, such as deployment_order and lifecycle parameters. //note: SO CNFM can read the DeploymentItems attributes including priorities for orchestration. 
      • sub. mapping added in standard ONAP way
    • Helm charts added to Artifacts/Deployment/HELM (similar to what is done today for onap zip cnf packages)
    • Original onboarded ASD csar is included in the same way as we do for ETSI.
    • Can we add anything specific to allow SO identify the package as ASD?; it could be done by SO deducing from the info already there (e.g. does it have a node template of the ASD type), but will be straightforward to add something explicitly if that is preferred, similar to what we have suggested in the TOSCA.meta
    • We need a way for SDC to recognise the onboarded csar as an ASD, for etsi we reply on presence of ETSI-... metdata. We can add something similar for ASD
      • we can use ASD-specific metadata the main manifest file
      • we can use the TOSCA.metadata model type flag

    ...

    file	types	Comments
    data.yaml	org.onap.asd.datatypes.deploymentItem:     derivedFrom: tosca.datatypes.Root     properties:         deployment_item_id:              type: string                      description: UUID of deployment item             required: true          artifact_type:             type: enum             values: ["HELM", "HELMFILE", "CRD"]             default: "HELM"             required: true         artifact_id:             type: string             description: UUID of artifact id             required: true         deployment_order:             type: integer             required: false         lifecycle_parameters:             type: list             entry_schema:                 type: string             required: false
    	org.onap.asd.datatypes.ext_cpd:     derivedFrom: tosca.datatypes.Root	TBD
    	org.onap.datatypes.enhanced_cluster_capabilities:     derivedFrom: tosca.datatypes.Root	TBD
    nodes.yaml	org.onap.asd.CNF:     derived_from: tosca.nodes.Root     properties:         asd_id:             type: string             description: UUID of ASD              required: true                  asc_schema_version:             type: string             description: version of ASD schema             required: true         asd_provider:             type: string             description: provider of AS and ASD             required: true                asd_application_name:             type: string             description: name of Application Service. Invariant for the AS lifetime             required: true                asd_application_version:             type: string             description: version of Application Service             required: true                asd_application_info_name:             type: string             description: Human readable name of Application Service. Can change during the AS lifetime             required: false         asd_info_description:             type: string             description: Human readable description of AS. Can change during the AS lifetime             required: false         asd_ext_cpd:             entry_schema:                 type: org.onap.asd.datatypes.ext_cpd             description: describes the externally exposed connection points of the application             type: list             required: false         enhanced_cluster_capabilities:             entry_schema:                 type: org.onap.datatypes.enhanced_cluster_capabilities             description: expected capabilities of the target cluster to aid placement of AS             type: list             required: false         deployment_items:             entry_schema:                 type: org.onap.asd.datatypes.deploymentItem            description: deployment artifacts            type: list              required: false
    resource-<asd>-template.yml	node_templates:     asd_instance:       type: org.onap.asd.CNF       metadata:         invariantUUID: 3948bd3d-f4e2-41a9-b3b4-edc6c6db927e         UUID: 05329593-52f8-482d-a967-8dbb28bb117a         name: Asd1.CNF         description: Not reusable inner VFC         category: Generic         version: '1.0'         customizationUUID: 59c10655-f68e-47d3-bf7b-d8f5698f6f75         type: ASD      // used be VFC         subcategory: Abstract         resourceVendor: d         resourceVendorRelease: 2.6.1         reourceVendorModelNumber: ''       properties:         asd_id: ASD Instance         asd_schema_version: 1.0.0   group:     Asd..helmA..module-0:       type: org.openecomp.groups.VfModule       metadata:         vfModuleModelName: Asd..helmA..module-0         vfModuleModelInvariantUUID: 766017db-5c11-47f9-a3c4-1fed0dbae9cb         vfModuleModelUUID: 57a35aad-4290-4b55-a0b2-150aad6da058         vfModuleModelVersion: '0.0'       properties:         min_vf_module_instances: 1         vf_module_label: helmA         max_vf_module_instances: 1         vf_module_type: Base         isBase: true         initial_count: 1         volume_group: false         deployment_order: 1         lifecycle_parameters:                       - "Values.db.fullBackupInterval"                       - "Values.db.walConsolidationInterval"      Asd..helmB..module-1:       type: org.openecomp.groups.VfModule       metadata:         vfModuleModelName: Asd..helmB..module-0         vfModuleModelInvariantUUID: 766017db-5c11-47f9-a3c4-1fed0dbae9cb         vfModuleModelUUID: 57a35aad-4290-4b55-a0b2-150aad6da058         vfModuleModelVersion: '0.0'       properties:         min_vf_module_instances: 0         vf_module_label: helmB         vf_module_type: Expansion         isBase: false         initial_count: 0         volume_group: false         deployment_order: 2         lifecycle_parameters:                       - "Values.db.initialWebReplicas"    substitution_mappings:     node_type: org.openecomp.resource.vf.Asd1     properties:       nf_naming:       - nf_naming       skip_post_instantiation_configuration:       - skip_post_instantiation_configuration       multi_stage_design:       - multi_stage_design       nf_function:       - nf_function       nf_naming_code:       - nf_naming_code       controller_actor:       - controller_actor       availability_zone_max_count:       - availability_zone_max_count       sdnc_artifact_name:       - sdnc_artifact_name       max_instances:       - max_instances       nf_type:       - nf_type       sdnc_model_version:       - sdnc_model_version       nf_role:       - nf_role       min_instances:       - min_instances       sdnc_model_name:       - sdnc_model_name	for the asd_instance, can we use the "type" for indicating "ASD" can we extend the org.openecomp.groups.VfModule to add an optional property for the VfModule order to represent the DeploymentItems order?       e.g., deployment_order can we extend the org.openecomp.groups.VfModule to add the lifecycle_parameters from the lifecycleParameters from the DeploymentItems?

    ...

    Create Service CSAR file

    • TOSCA-Metadata TASK #<23>#<30>: SDC generates TOSCA-Metadata directory and TOSCA.meta
      • TOSCA.meta
      • Definitions. TASK
      #<24>
      • #<31>: SDC maps the onboarding ASD models into the ONAP internal. Note: mapping is under discussion
      • annotations.yml
      • artifacts.yml
      • capabilities.yml
      • data.yml
      • groups.yml
      • interfaces.yml
      • nodes.yml
      • policies.yml
      • relationships.yml
      • asd_types.yaml.                            // instead of using ONAP type definitions, support the ASD model specific definitions are included; TBD
      • resource-<...>-template-inteface.yml (came from VF)
      • resource-<...>-template.yml
      • service-<...>-template-interface.yml
      • service-<...>-template.yml. (put input parameters, additional properties...)
    • Artifacts
      • Resources
        • <VF-name>
          • Deployment //TASK #<25>#<32>: use the "HELM" directory to contain Helm Charts
            • HELM
              • <helm files>
    • csar.meta
    • NS.mf