...
- 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 - 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
|
|
| 1 | US 2 | 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
|
|
| 1 | US 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
|
|
| 1 | US 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
|
|
| 1 | US 5 | SDC distributes Service CSAR to ONAP runtime components thru DMaaP - Assuming no SDC impact for this
|
|
| 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 - 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
...
- TOSCA-Metadata
- TOSCA.meta:
- It is generated by SDC, and SDC copies the following metadata and drops other custom metadata
- TASK #<7>: SDC copies the ASD-Entry-Definitions metadata from the onboarding App package. note: it is under discussion
e.g.,
TOSCA-Meta-File-Version: 1.0
...
- 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
- 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>: SDC generates TOSCA-Metadata directory and TOSCA.meta
- Definitions. 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 //TASK #<25>: use the "HELM" directory to contain Helm Charts
- csar.meta
- NS.mf
