Versions Compared

Key

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

...

PriorityUser StoryDescriptionJIRA Ticket
1US 1

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 introduce the ASD-related metadata in the following metadata for App package manifest file. By using the new metadata, SDC and orchestrator orchestrators know this package is for App and based on ASDIntroduce a new key name to metadata, " ASD-Entry-Definitions" in the TOSCA.meta

1US 2

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

  • SDC copies the ASD-Entry-Definitions 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

1US 3

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

1US 4

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

1US 5

SDC distributes Service CSAR to ONAP runtime components thru DMaaP

  • Assuming no SDC impact for this 

1US 6

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





...

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.

  • REQUIREMENT 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

...

The following describes the App package structure.

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

...

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

!------Files (note: it is allowed that its sub directories are placed under the root directory.Artifacts (additional artifacts files)Files 

!----- ChangeLog.txt

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

...

!----- file(s)

!----- signature(s)

!------Scripts

!----- install.sh

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


App Package Directory and File Details
  • MRF<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 
    • REQUIREMENT <3>: TASK #<3>: The App package shall introduce the following metadata to define the package type/model.
    • TASK #<4>: SDC shall detect the asd/app metadata and process the Application package onboarding path.
      • Note: metadata candidates. To be finalized (asd, app?? or else)
      metadata for App package. By using the new metadata, SDC and orchestrator know this package is based on ASD 
      • asd_id
      • app_provider_id
      • app_product_name
      • app_release_date_time
      • app_software_version                //we may use the asdApplicationVersion? 
      • app_package_version
      • compatible_specification_versions
      • e.g., app_main_descripter.mf

...

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

app_software_version: 1.0.0

app_package_version: 1.0compatible_specification_versions: 1.0.0


    • Define Source paths: 
      • Source: ChangeLog
      • Source: Definitions
      • Source: Images
      • Source: Artifacts
      • Source: LcmScripts
      • Source: License
      • Source: TOSCA-Metadata

...

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

    • TOSCA.meta
      • REQUIREMENT TASK #<4>: for ASD, use only ETSI-Entry-Manifest

...

  • 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

  • Files 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
    • ArtifactsDeployment
      • HELM             //REQUIREMENT TASK #<5>: 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

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

    • Scripts
      • <script> file

SDC creates VSP CSAR file for App Package Onboarding

  • TOSCA-Metadata
    • TOSCA.meta:
      • It is generated by SDC, and SDC copies the following metadata and drops other custom metadata 
      • REQUIREMENT TASK #<7>: SDC copies the ASD-Entry-Definitions metadata from the onboarding App package.  note: it is under discussion

...

Entry-Definitions: Definitions/main_app_template.yamlASD-Entry-

  • Definitions:

...

  • Definitions: SDC generates this directory based on the onboarding App package directory
    • Note: it is under discussion if we use the existing ONAP internal models after mapping from the ASD model, or put the ASD model separately. The second case will impact the existing ONAP runtime components, such as AAI, SDNC and others.
    • Note: the mapping between ASD and ONAP internal model is under discussion: 
      • ASD ↔ ONAP VF
      • DeploymentItems ↔ VF-Modules

...

    • main_app_template.yaml
    • GlobalSubstitutionTypesServiceTemplate.yaml.            // REQUIREMENT TASK #<8>: SDC generates this by including the app_main_descripter.mf informationdescripter.mf information

note: for App package onboarding, the following SDC internal structures are under discussion with the SDC team.

    •  onap (TBD)
      • _index.yml
      • artifacts.yml
      • capabilities.yml
      • data.yml
      • interfaces.yml
      • nodes.yml
      • relationships.yml
    • onapecomp                                // TBD
      • _index.yml
      • artifacts.yml
      • capabilities.yml
      • data.yml
      • interfaces.yml
      • nodes.yml
      • relationships.yml
    • openecomp-heat                       // REQUIREMENT TASK #<9>: SDC does not use this directory for the App Package
      • _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: REQUIREMENT TASK #<10>: SDC generates this directory by copying artifacts from the onboarding App package
    • <cnf>.mf                   // TASK #<>: based on the app/asd metadata in the onboarding manifest file, SDC creates app/asd-specific metadata (e.g., subcategory: ASD)
    • Definitions
      • ASD_1_0_types.yaml
      • <main_app_template>
    • <?>_cnf.mf
    • Definitions
      • main_app_template.yaml
    • Deployment: REQUIREMENT TASK #<11>: SDC preserves the original onboarding App package 
      • APP_PACKAGE.              // copy of the original AS package
    • Images: REQUIREMENT TASK #<12>: 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>
      .  
      • <image>
      • <image>
    • HELM (TBD)
      • <helm file>
      • <helm file>
    •  InformationalInformational
      • <Guide>
        • VSP_<?>_Information.txt
    • LcmScripts
      • <scripts>
    • Licenses
      • LICENSE.txt
    • TOSCA-Metadata: REQUIREMENT TASK #<13>: 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 (this is the preferred way for PoC)

  • TOSCA-Metadata: REQUIREMENT TASK #<14>: SDC generates TOSCA-Metadata directory and TOSCA.meta based on the corresponding VSP
    • TOSCA.meta
  • Definitions: REQUIREMENT TASK #<15>: SDC maps the onboarding ASD models into the ONAP internal. Note: mapping is under discussionSee the mapping section betlow.
    • artifacts.yml
    • capabilities.yml
    • data.yml (if mapping, extra date types will be here)
    • groups.yml
    • interfaces.yml
    •                 // TASK #<>: SDC extends data.yml for ASD types
    • groups.yml.            // TASK #<>: SDC extends the VF-Module for additional properties
    • interfaces.yml
    • nodes.yml               // TASK #<>: SDC extends nodes.yml for ASD-based CNFnodes.yml (add ASD nodes)
    • policies.yml
    • relationships.yml
    • resource-<...>-template.yml. REQUIREMENT TASK #<16>: SDC generates this based on the onboarding ASD model
    • resource-<...>-template-interface.yml REQUIREMENT TASK #<17>: SDC generates this based on the onboarding ASD model
  • Artifacts
    • Deployment: REQUIREMENT TASK #<18>: SDC preserves the original onboarding App package and additional License files thru SDC UI
      • AS_PACKAGE (original)
        • <App>.csar           // original vendor CSAR
      • VENDOR_LICENSE
      • VF_LICENSE
    • HELM
      • <HELM Chart A file>
      • <HLEM Chart B file>
    •  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: Network ASD            // TASK #<>: SDC extends the subcategory to have ASD;    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:
        asd_id: ASD Instance
        asc_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
    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

...

  • TOSCA-Metadata
    • TOSCA.meta REQUIREMENT TASK #<19>: SDC generates TOSCA-Metadata directory and TOSCA.meta
  • Definitions: REQUIREMENT TASK #<20>: 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.       // REQUIREMENT TASK #<21>: SDC UI modifies onboarding ASD for changing the default values
    • resource-<...>-template-interface.yml.  // REQUIREMENT TASK #<22>: SDC UI modifies onboarding ASD for changing the default values.
  • Artifacts
    • Deployment
      • AS_PACKAGE
        • AS_<...>DataTypes.csar
      • HELM
        • <HELM Chart file>
        • <HLEM Chart file>
      •  VENDOR_LICENSE
        • vendor-license-model.xml

...

Create Service CSAR file

  • TOSCA-Metadata REQUIREMENT TASK #<23>: SDC generates TOSCA-Metadata directory and TOSCA.meta
    • TOSCA.meta
  • Definitions. REQUIREMENT TASK #<24>: 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 //REQUIREMENT TASK #<25>: use the "HELM" directory to contain Helm Charts
          • HELM
            • <helm files>
  • csar.meta
  • NS.mf