Versions Compared

Old Version 74

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version 75

changes.mady.by.user Byung-Woo Jun

Saved on

Key

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

Note: work in progress

Table of Contents

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.

App Onboarding Package

...

Requirement 


RequirementDescriptionJIRA
R1

In the TOSCA.meta, reuse the same metadata structure defined by TOSCA and ETSI

  • TOSCA-Meta-File-Version:
  • CSAR-Version:
  • Created-By:
  • Entry-Definitions:

R2

In the TOSCA.meta, reuse the same ETSI defined Entry Keywords

  • ETSI-Entry-Manifest:
  • ETSI-Entry-Change-Log:                  // it optional
  • ETSI-Entry-Licenses:                        // it is optional 
  • ETSI-Entry-Tests:                              // it is optional 
  • ETSI-Entry-Certificate:                     // it is optional

R3

In the main manifest file, reuse the metadata structure defined by ETSI with new keywords (the following proposal is under discussion)

  • oran_id: 2116fd24-83f2-416b-bf3c-ca1964793aca
  • oran_product_name: vCU
  • oran_provider_id: Ericsson
  • oran_package_version: 1.0
  • oran_release_date_time: 2021-10-21T11:30:00+05:00
  • oran_entry_definition_type: [asd, app, app-asd, …]

R4

In the main manifest file, reuse the artifact security as defined by ETSI

  • Source:
  • Signature:                // for security option #1
  • Certificate:               // for security option #1

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

  • non_mano_artifact_sets:
    • onap_vest_events:
      • source:
    • onap_pm_directory:
      • source:
    • onap_yang_module:
      • source:
    • onap_others:
      • source:
      • source:

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.
EpicDescriptionJIRA
SDC Shall Support Application Package onboarding and distribution
  • 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.

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySDC-3777




SDC User Story

PriorityUser StoryDescriptionJIRA Ticket
1US 1

The SDC supports the App Onboarding Package shall be , which is 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
  • In the main manifest file, reuse the metadata structure defined by ETSI with new keywords. 
  • By using the new metadata, SDC and orchestrators know this package is for App and based on ASD
    • oran_id: 2116fd24-83f2-416b-bf3c-ca1964793aca
    • oran_product_name: vCU
    • oran_provider_id: Ericsson
    • oran_package_version: 1.0
    • oran_release_date_time: 2021-10-21T11:30:00+05:00
    • oran_entry_definition_type: [asd, app, app-asd, …]

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

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





...