Note: work in progress
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
Priority | User Story | Description | JIRA Ticket |
---|---|---|---|
1 | US 1 | The App Package shall be compliant to the ETSI NFV SOL004 CSAR structure with the TOSCA-Metadata directory
| |
1 | US 2 | SDC creates an SDC VSP package thru onboarding of an Application Service CSAR based on ASD
| |
1 | US 3 | SDC creates AS internal CSAR (VF resource) by importing VSP CSAR to add CNF/Application based on ASD
| |
1 | US 4 | Create an Service CSAR consists of one or more CNF/Application based on ASD
| |
1 | US 5 | SDC distributes Service CSAR to ONAP runtime components thru DMaaP
| |
1 | US 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
| |
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.
- REQUIREMENT #<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 the App package structure.
Note: blue directory names and file type suffixes are requested by SOL004
REQUIREMENT #<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
!------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 <3>: 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
- REQUIREMENT <3>: introduce the following metadata for App package. By using the new metadata, SDC and orchestrator know this package is based on 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
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
- Define Source paths:
- TOSCA-Metadata directory: It contains the entry points:
<ETSI keynames extension>
- TOSCA.meta
- REQUIREMENT #<4>: 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.
- REQUIREMENT #<4>: introduce a new key name to metadata, "ASD-Entry-Definitions"
- TOSCA.meta
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: app_main_descripter.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>. // or image reference
- <image> // or image reference
- Licenses
- LICENSE.txt
- Artifacts
- Deployment
- HELM //REQUIREMENT #<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
- HELM //REQUIREMENT #<5>: use the "HELM" directory to contain Helm Charts
- Deployment
- Images
// REQUIREMENT #<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 #<7>: SDC copies the ASD-Entry-Definitions metadata from the onboarding App package. note: it is under discussion
- TOSCA.meta:
e.g.,
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: ASDC Onboarding portal
Entry-Definitions: Definitions/main_app_template.yaml
ASD-Entry-Definitions: Definitions/main_app_template.yaml
- 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 #<8>: SDC generates this by including the app_main_descripter.mf information
- 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 #<9>: SDC does not use this directory for the App Package
_index.ymldata.ymlgroups.ymlnodes.yml
- tosca
- _index.yml
- artifacts.yml
- capabilities.yml
- data.yml
- groups.yml
- interfaces.yml
- nodes.yml
- policies.yml
- relationships.yml
- Artifacts: REQUIREMENT #<10>: SDC generates this directory by copying artifacts from the onboarding App package
- <?>_cnf.mf
- Definitions
- main_app_template.yaml
- Deployment: REQUIREMENT #<11>: SDC preserves the original onboarding App package
- APP_PACKAGE. // copy of the original AS package
- Images: REQUIREMENT #<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>
- Informational
- <Guide>
- VSP_<?>_Information.txt
- <Guide>
- LcmScripts
- <scripts>
- Licenses
- LICENSE.txt
- TOSCA-Metadata: REQUIREMENT #<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
- TOSCA-Metadata: REQUIREMENT #<14>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- TOSCA.meta
- Definitions: REQUIREMENT #<15>: SDC maps the onboarding ASD models into the ONAP internal. Note: mapping is under discussion.
- 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. REQUIREMENT #<16>: SDC generates this based on the onboarding ASD model
- resource-<...>-template-interface.yml REQUIREMENT #<17>: SDC generates this based on the onboarding ASD model
- Artifacts
- Deployment: REQUIREMENT #<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
- AS_PACKAGE (original)
- HELM
- <HELM Chart A file>
- <HLEM Chart B file>
- Informational
- OTHER
- VSP_<?>_Information.txt
- OTHER
- Deployment: REQUIREMENT #<18>: SDC preserves the original onboarding App package and additional License files thru SDC UI
- csar.meta
- Files. (missing from SDC****; Its handling is under discussion)
- Images
- <image>
- <image>
- Images
- 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 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
Create VF CSAR file thru the SDC Multi Model Way. // Propose to use for the AS Package Onboarding
- TOSCA-Metadata
- TOSCA.meta REQUIREMENT #<19>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- Definitions: REQUIREMENT #<20>: for the Multi Model way, SDC does not use ONAP internal model. Note: impact to the existing ONAP components are under discussion.
-
artifacts.ymlcapabilities.ymldata.ymlgroups.ymlinterfaces.ymlnodes.ymlpolicies.ymlrelationships.yml- asd_types.yaml. // instead of using ONAP type definitions, support the ASD model specific definitions are included
- resource-<...>-template.yml. // REQUIREMENT #<21>: SDC UI modifies onboarding ASD for changing the default values
- resource-<...>-template-interface.yml. // REQUIREMENT #<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
- AS_PACKAGE
- Deployment
e.g.,
<vendor-license-model xmlns="http://xmlns.openecomp.org/asdc/license-model/1.0">
<vendor-name>VendorA</vendor-name>
- VF_LICENSE
- vf-license-model.xml
- VF_LICENSE
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_<?>_Information.txt
- OTHER
- Informational
- csar.meta
Create Service CSAR file
- TOSCA-Metadata REQUIREMENT #<23>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- TOSCA.meta
- Definitions. REQUIREMENT #<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 #<25>: use the "HELM" directory to contain Helm Charts
- HELM
- <helm files>
- HELM
- Deployment //REQUIREMENT #<25>: use the "HELM" directory to contain Helm Charts
- <VF-name>
- Resources
- csar.meta
- NS.mf