Note: work in progress
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 - TOSCA-Meta-File-Version:
- CSAR-Version:
- Created-By:
- Entry-Definitions: // e.g., Definitions/asd.yml
|
|
| R2 | In the TOSCA.meta, reuse the same ETSI defined Entry Keywords - ETSI-Entry-Manifest: // e.g., asd.mf
- ETSI-Entry-Change-Log: // it Is optional for ASD
- ETSI-Entry-Licenses: // it is optional for ASD
- ETSI-Entry-Tests: // it is optional for ASD
- ETSI-Entry-Certificate: // it is optional for ASD
|
|
| R3 | In the main manifest file, reuse the metadata structure defined by ETSI with new keywords Note: the following proposal is under discussion - application_name: // e.g., vCU
- application_provider: // e.g., Ericsson
- release_date_time: // e.g., 2021-10-21T11:30:00+05:00
- entry_definition_type: [asd]
| Name | Value | Notes | Qualifier |
|---|
| application_name | A sequence of UTF-8 characters | The value shall be identical to those specified in the MainServiceDescriptor, e.g., asdApplicationName in ASD | O | | application_provider | A sequence of UTF-8 characters | The value shall be identical to those specified in the MainServiceDescriptor, e.g., asdProvider in ASD | O | | release_date_time | A string formatted according to IETF RFC 3339 | Timestamp of the package release time | M | | entry_definition_type | enum[asd] | asd; only ASD is included in the package | M |
Note: there could be additional optional keywords. |
|
| 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:
- onap_pm_directory:
- onap_yang_module:
- onap_others:
|
|
...
| 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 - Supports the ETSI NFV SOL004 version ?? (3.3.1, 2.7.1, 2.6.1 and 2.5.1)
- For SDC onboarding, Supports the App package has the TOSCA-Metadata directory and the following metadata
- Reuse the same metadata structure defined by TOSCA and ETSI
- Reuse the same ETSI defined Entry keywords; only requires ETSI-Entry-Manifest
- Supports the ASD_types.yaml which defines 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 supports the following new manifest metadata, which will be used by the orchestrators to distinguish the package is for App and based on ASD
- application_name
- application_provider
- release_date_time
- entry_definition_type: [asd]
| | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | SDC-3778 |
|---|
|
| 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
- If VSP model can be ignored, this mapping can be skipped
- SDC generates the GlobalSubstitutionTypesServiceTemplate.yaml by including the app_main_descripter.mf information
- SDC generates Artifacts directory by copying artifacts from the onboarding App package
- SDC should copy all the onboarding artifacts to VSP
- 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
- SDC uses the Artifacts > HELM directory to hold the onboarding Helm Charts
| | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | SDC-3779 |
|---|
|
| 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
- entry_defintion_type in the ASD package will be copied into TOSCA.meta
- SDC maps the onboarding ASD models into the ONAP internal model
- Design suggestion: ASD ↔ ONAP VF, DeploymentItems ↔ VF-Modules
- see the mapping, MappingbetweenASDandSDCInternalModel
extend the org.openecomp.groups.VfModule to hold the DeploymentItems properties, such as deployment_order and lifecycl parameters Note: SO CNFM can read the properties from ASD.
- 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 uses the Artifacts > HELM directory to hold the onboarding Helm Charts
- 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
| | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | SDC-3780 |
|---|
|
| 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
| | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | SDC-3781 |
|---|
|
| 1 |
| US 5 | SDC distributes Service CSAR to ONAP runtime components thru DMaaP - Assuming no SDC impact for this
| 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 - 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
|
| 1 |
| US 7 | Enhance TOSCA parser for ASD | | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | SDC-3902 |
|---|
|
| 1 |
SDC Onboarding and Distribution Sequence
...
