Application Package Onboarding to SDC

Note: work in progress

SDC Package Onboarding Process

SDC Epic

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

SDC User Story

Priority	User Story	Description
1	US 1	Actor: Create an SDC VSP package thru onboarding of an Application Service CSAR based on ASD create metadata to distinguish the model type (e.g., ASD) create metadata to distinguish the artifact type (e.g., HELM)
1	US 2	Actor: Create AS internal CSAR (VF resource) by importing VSP CSAR to add CNF/Application based on ASD
1	US 3	Actor: Create an Service CSAR consists of one or more CNF/Application based on ASD
1	US 4	Actor: Distribute Service CSAR to ONAP runtime components thru DMaaP
1	US 5	Actor: Distribute associated Helm Charts to the target Helm Artifact Repository
1	US 6	Actor: Distribute associated Image files to the target Image Repository

SDC Onboarding and Distribution Sequence

SDC App Package Onboarding

Vendor App Package

Application Service Package conforms to ETSI SOL004 (inspired) until SOL004 makes the SOL001 VNFD optional.

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.

REQUIREMENT #<>: 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 assume 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 the App package structure.

Note: blue directory names and file type suffixes are requested by SOL004

REQUIREMENT #<>: 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

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

!----- 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

- REQUIREMENT #<>: introduce the following 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
  - app_package_version
  - compatible_specification_versions
  - cnfm_info

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

compatible_specification_versions: 1.0.0

cnfm_info: cnfm:v1.0.0

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

TOSCA-Metadata directory: It contains the entry points:

- TOSCA.meta
  - REQUIREMENT #<>: introduce a new key name to metadata, "ASD-Entry-Definitions"
    - note: we are evaluating the above manifest metadata is enough to distinguish the app package model from other models.

e.g.,

TOSCA-Meta-File-Version: 1.0

CSAR-Version: 1.1

Created-By: <vendor>

Entry-Definitions: Definitions/main_app_template.yaml

ASD-Entry-Definitions: Definitions/main_app_template.yaml

ETSI-Entry-Manifest: f5_FW_cnf.mf

ETSI-Entry-Licenses: Licenses

ETSI-Entry-Change-Log: ChangeLog.txt

Definitions
- ASD_1_0_types.yaml // node_types, artifact_types, data_types
- main_app_template.yaml. // descriptor leveraging ASD

e.g., Sample main_app_template.App

Files (optional; Images, Licenses and Artifacts directories can be located under the root directory)
- Images
  - <image>
  - <image>
- Licenses
  - LICENSE.txt
- Artifacts
  - Deployment
    - HELM //Requirement #<>: use the "HELM" directory to contain Helm Charts
      - <Helm Chart file>
      - <Helm Chart file>
Scripts
- <script> file

Create VSP CSAR file

TOSCA-Metadata
- TOSCA.meta: It is generated by SDC, and ETSI and other custom metadata will be not copied to here.

e.g.,

TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: ASDC Onboarding portal
Entry-Definitions: Definitions/f5_FW_cnf.yaml

Definitions (generated by SDC)
- f5_FW_cnf.yaml
- GlobalSubstitutionTypesServiceTemplate.yaml. //include asd_types.yaml
- 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 // TBD~~
  - ~~_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 (copy into this)
- F5_FW_cnf.mf
- Definitions
  - f5_FW_cnf.yaml
- Deployment
  - AS_PACKAGE. // copy of the original AS package
- Images
  - <image>
  - <image>
- Informational
  - <Guide>
    - VSP_f5_Information.txt
- LcmScripts
  - <scripts>
- Licenses
  - LICENSE.txt
- 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 OLD way; not used for the ASD~~

TOSCA-Metadata (generated by SDC)
- TOSCA.meta
Definitions
- artifacts.yml
- capabilities.yml
- data.yml (if mapping, extra date types will be here)
- groups.yml
- interfaces.yml
- nodes.yml (add ASD nodes)
- policies.yml
- relationships.yml
- resource-<...>-template.yml. (represent ASD)
- resource-<...>-template-interface.yml (represent ASD)
Artifacts
- Deployment
  - AS_PACKAGE (original)
  - VENDOR_LICENSE
  - VF_LICENSE
- Informational
  - OTHER
    - VSP_f5_Information.txt
csar.meta
Files. (missing from SDC****)
- Images
  - <image>
  - <image>

Create VF CSAR file thru the SDC Multi Model Way. // Propose to use for the AS Package Onboarding

TOSCA-Metadata
- TOSCA.meta
Definitions
- ~~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. // SDC UI modifies
- resource-<...>-template-interface.yml. // SDC UI modifies
Artifacts
- Deployment
  - AS_PACKAGE
    - AS_<...>DataTypes.csar
  - VENDOR_LICENSE
    - vendor-license-model.xml

e.g.,

<vendor-license-model xmlns="http://xmlns.openecomp.org/asdc/license-model/1.0">

<vendor-name>VendorA</vendor-name>

<entitlement-pool-list/>

<license-key-group-list/>

</vendor-license-model>

- - VF_LICENSE
    - vf-license-model.xml

e.g.,

<vf-license-model xmlns="http://xmlns.openecomp.org/asdc/license-model/1.0">

<vendor-name>VendorA</vendor-name>

<vf-id>367db414413b4f3e96fcb92df023df27</vf-id>

<feature-group-list/>

</vf-license-model>

- Informational
  - OTHER
    - VSP_f5_Information.txt
csar.meta

Create Service CSAR file

TOSCA-Metadata
- TOSCA.meta
Definitions
- 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
- 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
      - HELM
        <helm files>
csar.meta
NS.mf

Space shortcuts

Page tree

Note: work in progress

SDC Package Onboarding Process

SDC Epic

SDC User Story

SDC Onboarding and Distribution Sequence

Vendor App Package

SOL004 Package CSAR Structure

App Package structure that is defined in ETSI NFV SOL004

Create VSP CSAR file