Note: work in progress
SDC Package Onboarding Process
SDC User Story
...
Table of Contents
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
Jira server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-1043
Requirement | Description | Comments | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
R1 | In the TOSCA.meta, reuse the same metadata structure defined by TOSCA and ETSI
| |||||||||||||||||||||
R2 | In the TOSCA.meta, reuse the same ETSI defined Entry Keywords
| |||||||||||||||||||||
R3 | In the main manifest file, reuse the metadata structure defined by ETSI with new keywords Note: the following proposal is under discussion
Note: there could be additional optional keywords. | |||||||||||||||||||||
R4 | In the main manifest file, reuse the artifact security as defined by ETSI
For Jakarta PoC, ONAP shall support the security option #2. So, the App provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the App provider public key. -- AppPackage.zip –- AppPackage.csar –- AppPackage.csar signature –- Signing certificate | |||||||||||||||||||||
R5 | In the main manifest file non_mano_artifact_sets, reuse the same structure with the existing keywords defined by ONAP
|
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
Application Package Onboarding and Distribution to ONAP
The following diagram depicts Application Package onboarding and distribution to ONAP and repositories.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
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.
Epic | Description | JIRA | Priority | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
SDC Shall Support Application Package onboarding and distribution |
|
| 1 | ||||||||
SDC User Story
User Story | Description | JIRA Ticket | Priority | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
US 1 | SDC supports the App Onboarding Package, which is 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
| No impact | 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
| 1 | |||||||||
US 7 | Enhance TOSCA parser for ASD |
| 1 |
SDC Onboarding and Distribution Sequence
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
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
- Define Source paths:
- 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.
Keyname | Required | Type | Description |
---|---|---|---|
ETSI-Entry-Manifest | Yes | string | Location of the Manifest file |
ETSI-Entry-Change-Log | No | string | Location of the Change history file |
ETSI-Entry-Tests | No | string | Location of the Testing files |
ETSI-Entry-Licenses | No | string | Location of the Licensing information |
ETSI-Entry-Certificate | No | string | Location of the Certificate file |
- 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
- 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
- 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
Code Block | ||
---|---|---|
| ||
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
Code Block | ||
---|---|---|
| ||
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" |
- 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 #<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
- HELM //TASK #<7>: use the "HELM" directory to contain Helm Charts
- Images
// TASK #<8>: If values.schema.json files exist, SDC UI uses them to validate values.yaml files and populates customizable values
- Scripts
- <script> file
- Scripts
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
- TASK #<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.
- 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
- 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. // TASK #<10>: SDC copies the asd manifest entries to this main TOSCA definition file
- GlobalSubstitutionTypesServiceTemplate.yaml. // TASK #<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
- onap (TBD)
- Artifacts: TASK #<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_types.yaml
- <main_app_template>.yaml
- Deployment: TASK #<14>: SDC preserves the original onboarding App package
- ORAN_PACKAGE // a directory where the original package is stored
- Images: TASK #<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
- <Guide>
- LcmScripts
- <scripts>
- Licenses
- LICENSE.txt
- TOSCA-Metadata: TASK #<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)
- Definitions
Create VF CSAR file - an original way (most likely, this is the option for PoC)
- TOSCA-Metadata: TASK #<17>: SDC generates TOSCA-Metadata directory and TOSCA.meta based on the corresponding VSP
- TOSCA.meta
- Definitions: TASK #<18>: SDC maps the onboarding ASD models into the ONAP internal. See the mapping section 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 #<22>: SDC generates this based on the onboarding ASD model
- resource-<...>-template-interface.yml TASK #<23>: SDC generates this based on the onboarding ASD model
- Artifacts
- Deployment: TASK #<24>: SDC preserves the original onboarding App package and additional License files thru SDC UI
- ORAN_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
- ORAN_PACKAGE (original)
- Deployment: TASK #<24>: 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>
- 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: Application Service Descriptor // TASK #<25>: SDC extends the subcategory to have Application 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 Instanceoran_product_name: vFW
oran_provider_id: vendorA
oran_package_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 #<26>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- Definitions: TASK #<27>: 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. // TASK #<28>: SDC UI modifies onboarding ASD for changing the default values
- resource-<...>-template-interface.yml. // TASK #<29>: SDC UI modifies onboarding ASD for changing the default values.
- Artifacts
- Deployment
- ORAN_PACKAGE
- AS_<...>DataTypes.csar
- HELM
- <HELM Chart file>
- <HLEM Chart file>
- IMAGE
- <image>
- <image>
- VENDOR_LICENSE
- vendor-license-model.xml
- ORAN_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
Mapping between ASD and SDC Internal Model
- 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//note: SO CNFM can read the DeploymentItems attributes including priorities for orchestration.org.openecomp.groups.VfModule
to hold the DeploymentItems properties, such as deployment_order and lifecycle parameters.- 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 |
| |
| TBD | |
| TBD | |
nodes.yaml |
| |
resource-<asd>-template.yml |
|
e.g., deployment_order
|
Create Service CSAR file
- TOSCA-Metadata TASK #<30>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- TOSCA.meta
- Definitions. TASK #<31>: SDC maps the onboarding ASD models into the ONAP internal. Note: mapping is under discussion
...
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., ETSI, ASD, HOT, others)
- create metadata to distinguish the artifact type (e.g., HELM)
...
Actor:
Create AS internal CSAR (VF resource) by importing VSP CSAR to add CNF/Application based on ASD
...
Actor:
Create an Service CSAR consists of one or more CNF/Application based on ASD
...
Actor:
Distribute Service CSAR to ONAP runtime components thru DMaaP
...
Actor:
Distribute associated Helm Charts to the target Helm Artifact Repository
...
Actor:
Distribute associated Image files to the target Image Repository
Sequence
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Vendor App Package
Application Service Package conforms to ETSI SOL004 (inspired) until SOL004 makes the SOL001 VNFD optional.
SOL004 Package CSAR Structure
ONAP supports SOL004-conformed CSAR with the TOSCA-Metadata directory, which includes the TOSCA.meta metadata file providing and entry information for processing a CSAR file.
e.g.,
!------TOSCA-Metadata
!------TOSCA.meta
!------TOSCA.meta.sig.cms
!------Definitions
!----- MRF.yaml
!----- MRF.yaml.sig.cms (signature)
!----- OtherTemplates (e.g. type definitions)
|----- OtherTemplates signatures
!------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
!----- MRF.mf
Note: SOL001 VNFD requirement in the current SOL004 needs to be changed; i.e., make SOL001 VNFD in SOL004 optional.
Root directory
- MRF.mf
e.g., f5_FW_cnf.mf
- TOSCA-Metadata directory
- TOSCA.meta
e.g.,
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: <vendor>
Entry-Definitions: Definitions/f5_FW_cnf.yaml
ETSI-Entry-Manifest: f5_FW_cnf.mf
ETSI-Entry-Licenses: Licenses
ETSI-Entry-Change-Log: ChangeLog.txt
<keynames extension>
- Definitions
- asd_types.yaml. // node_types, artifact_types, data_types
- f5_FW_cnf.yaml. // descriptor leveraging ASD
e.g., Sample App
- Files
- Images
- <image>
- <image>
- Licenses
- LICENSE.txt
- Artifacts
- Deployment
- HELM
- <Helm Chart file>
- <Helm Chart file>
- AS_PACKAGE
- ETSI_PACKAGE
- HELM
- Deployment
- Scripts
- Images
Create VSP CSAR file
- TOSCA-Metadata
- TOSCA.meta
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
- f5_FW_cnf.yaml
- GlobalSubstitutionTypesServiceTemplate.yaml. //TBD
-
onap (TBD)_index.ymlartifacts.ymlcapabilities.ymldata.ymlinterfaces.ymlnodes.ymlrelationships.yml
onapecomp // TBD_index.ymlartifacts.ymlcapabilities.ymldata.ymlinterfaces.ymlnodes.ymlrelationships.yml
openecomp-heat // TBD_index.ymldata.ymlgroups.ymlnodes.yml
- tosca
_index.ymlartifacts.ymlcapabilities.ymldata.ymlgroups.ymlinterfaces.ymlnodes.ymlpolicies.ymlrelationships.yml- asd_types.yaml
- Artifacts
- 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
- <Guide>
- LcmScripts
- <scripts>
- Licenses
- LICENSE.txt
- TOSCA-Metadata
- TOSCA.meta.original
- ChangeLog.txt
- vendor-license-model.xml
- vf-license-model.xml
Create VF CSAR file - an OLD way; not used for the ASD
- TOSCA-Metadata
- TOSCA.meta
- Definitions
- artifacts.yml
- capabilities.yml
- data.yml
- groups.yml
- interfaces.yml
- nodes.yml
- policies.yml
- relationships.yml
- resource-<...>-template.yml
- resource-<...>-template-interface.yml
- Artifacts
- Deployment
- AS_PACKAGE
- VENDOR_LICENSE
- VF_LICENSE
- Informational
- OTHER
- VSP_f5_Information.txt
- OTHER
- Deployment
- csar.meta
Create VF CSAR file thru the SDC Multi Model Way. // Propose to use for the AS Package Onboarding
- TOSCA-Metadata
- TOSCA.meta
- Definitions
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
- resource-<...>-template-interface.yml
- Artifacts
- Deployment
- AS_PACKAGE
- AS_<...>DataTypes.csar
- 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_f5_Information.txt
- OTHER
- Informational
- 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; 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 #<32>: use the "HELM" directory to contain Helm Charts
- HELM
- <helm files>
- HELM
- Deployment //TASK #<32>: use the "HELM" directory to contain Helm Charts
- <VF-name>
- Resources
- csar.meta
- NS.mf