Versions Compared

Key

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

Note: work in progress

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 Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyREQ-1043


RequirementDescriptionComments
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

oran_application_name

new keywords

Note: the following proposal is under discussion

  • application_name:                             // e.g., vCU
  • application_provider:                        // e.g., Ericsson
  • release_date_time:                             // e.g., vCUoran_application_provider:                        // ., 2021-10-21T11:30:00+05:00
  • entry_definition_type: [asd]
NameValueNotesQualifier
application_nameA sequence of UTF-8 charactersThe value shall be identical to those specified in the MainServiceDescriptor, e.g., asdApplicationName in ASDO
application_providerA sequence of UTF-8 charactersThe value shall be identical to those specified in the MainServiceDescriptor, e.g.,
Ericssonoran_
asdProvider in ASDO
release_date_time
:                           // e.g., 2021-10-21T11:30:00+05:00oran_
A string formatted according to IETF RFC 3339Timestamp of the package release timeM
entry_definition_type
:
enum[asd]
Image Removed
asd; only ASD is included in the packageM

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:
      • source:
    • onap_pm_directory:
      • source:
    • onap_yang_module:
      • source:
    • onap_others:
      • source:
      • source:

...

Gliffy
macroIdbc311036-7906-4321-b5ac-f08422660eef
displayNameASD App Onboarding Distribution - Jakarta
nameASD App Onboarding Distribution - Jakarta
pagePin2120

SDC Package Onboarding Process

...

User StoryDescriptionJIRA TicketPriority
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
    • oran_application_name
    • oran_application_provider
    • oran_release_date_time
    • oran_entry_definition_type: [asd]

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-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 Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-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 Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-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 Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-3781

1
US 5

SDC distributes Service CSAR to ONAP runtime components thru DMaaP

  • Assuming no SDC impact for this 
No impact1
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 7Enhance TOSCA parser for ASD

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-3902

1

SDC Onboarding and Distribution Sequence

...

  • 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 org.openecomp.groups.VfModule to hold the DeploymentItems properties, such as deployment_order and lifecycl parameterslifecycle parameters. //note: SO CNFM can read the DeploymentItems attributes including priorities for orchestration. 
    • 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

...

filetypesComments
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?

...