Page History

Table of Contents

Note: Work in Progress

Requirement

Key Contacts - @Byung-Woo Jun (Ericsson), ...

Executive Summary - Provide ASD-based CNF orchestration support through SO and its sub-components, CNFM and CNF Adapter using K8S

• Support for provisioning ASD-based CNFs using an external K8s Manager
• Leverage and enhance SO capabilities and adding new capabilities for ASD- and Helm-based CNF orchestration

Business Impact - Enables operators and service providers to orchestrate ASD-based CNFs services along with the VNFs and PNFs

Business Markets - All operators and service providers that are intended to use the ASD-based CNFs along with PNFs / VNFs

Funding/Financial Impacts - Reduction in the footprint of the ONAP for CNF support

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider

JIRA:

Epic

User Story

Overall Process

• Pre-Conditions
  • SDC accepts onboarding App packages, including ASD and DeploymentItems models, Helm Charts, Images and other artifacts, what allows to keep decomposition of Service instance
  • SO subscribes and receives package notifications from SDC
• ASD-Based CNF LCM Orchestration
  • Based on the notifications, SO ASDC Controller queries for the App packages from SDC, and stores models and artifacts to SO Catalog Database
  • MACRO workflow in SO is used for orchestration

ASD-Based App Package Type

• The Resource VF(s) in the onboarded Service CSAR will have the following resource main manifest file
  
  • oran_application_name
  • oran_application_provider
  • oran_release_date_time
  • oran_entry_definition_type [ "asd"]
• SO distinguishes the App package based on the "oran_entry_defintion_type" metadata.
  • If it is "asd", SO will process the package as the ASD-based CNF.
  • SO delegates the ASD-based CNF orchestration to the CNF Manager

LCM Architecture Overview

The following diagram depicts LCM Architecture for the ASD-based CNF.

SO Internal Architecture

The following diagram depicts SO internal architecture for the ASD-based orchestration:

Design and Distribution of ASD Service CSAR - Day 0

The following sequence diagram depicts design and distribution of ASD service CSAR.

@startuml
participant Designer
participant Admin
participant SDC
participant SO_Client
participant SO
participant CNFM
participant CNF_Adapter
participant K8S_Plugin
participant AAI
participant K8S_Cluster

autonumber 

group ASD PACKAGE Distribution
	hnote over SDC : SDC supports ASD-based Service CSAR
    Designer -> SDC : Onboarding ASD App Package
    SDC --> SDC : Onboards ASD App Package and\ngenerates Service CSAR
    SDC -> SO : Distribute Service CSAR
    SDC -> AAI : Distribute Service CSAR
    SDC -> K8S_Cluster : Distribute Service CSAR
end  

group K8S Cluster Admin
	hnote over Admin : Admin accesses K8S Cluster
    Admin -> K8S_Cluster : Create/Update/Configure K8S Cluster
    Admin -> AAI : Add/Register K8S Cluster
    AAI --> AAI : Add the tenant
    AAI -> K8S_Plugin : Post Connectivity Info (Kubconfig file)
end



@enduml

Instantiation of ASD Service CSAR - Day 1

The following sequence diagram depicts instantiation of ASD-based CNF.

@startuml
participant SO_Client
participant SO
participant SO_BPMN
participant CNFM
participant AAI
participant SDNC
participant CDS
participant OOF
participant ASD_Catalog_Mgr
participant Helm_Repository
participant CNF_Adapter
participant K8S_Plugin
participant K8S_Cluster

autonumber 

group ASD-Based CNF Instantiation
    SO_Client -> SO : Create Service
    SO -> SO_BPMN : Process and Decompose Service
    SO_BPMN -> AAI : Create Service Instance
opt Service-Level Homing
    SO_BPMN -> OOF : Homing Information (optional for PoC)
    OOF -> SO_BPMN : Receive Homing Information (optional for PoC)
end
    SO_BPMN --> SO_BPMN : Process Model Info & Decide flows      
    SO_BPMN -> CNFM : Delegate Resource Orchestration,\npass input parameters
    CNFM -> ASD_Catalog_Mgr : Get ASD
    CNFM -> Helm_Repository : Get associated Helm Charts
    CNFM --> CNFM : Process and decompose ASD and DeploymentItems\n(VF & Vf-Modules)
    CNFM --> CNFM : get DeploymentItem order and create a sequence list
loop
    CNFM -> AAI : Create vf-module
    CNFM -> SDNC : Assign vf-module
    SDNC -> CDS: Assign vf-module
    CDS --> CDS : Build RB Profile
    CDS -> SDNC : Assign result
    SDNC -> CNFM : vf-module assigned
    CNFM -> CNF_Adapter : Assign vf-module
    CNF_Adapter -> K8S_Plugin : RB Profile (Helm enrichment)
    CNF_Adapter -> CNFM : vf-module assigned
    CNFM -> AAI : Update vf-module
    CNFM --> CNFM : Dry run for getting K8S resource\n(Vf-Module)
    CNFM -> OOF : get Homing Information per resource\n(Vf-Module)
    CNFM -> CNF_Adapter : Create vf-module in K8S
    CNF_Adapter -> K8S_Plugin : Create vf-module in K8S\n(RB Instance)
    K8S_Plugin -> K8S_Cluster : Install Helm Chart
    K8S_Plugin -> CNF_Adapter : K8S Resource Instance Status
    CNF_Adapter -> CNFM : vf-module in K8S created
    CNFM -> AAI : Update vf-module

end
end  



@enduml

AAI Data Model

AAI CNF Model - Overview

Note: the following overview came from the Direct CNFO AAI CNF Model. We will start it from here and will finalize the AAI model of ASD-based CNF.

• Currently no CNF Resources information is visible in ONAP AAI - agree
• Some interfaces are already implemented (Multicloud k8s Status/Query API) that
  allow retrieval of detailed resources information - plan to leverage existing interfaces if they are appropriate
• Initial implementation of CNF Model in AAI should be simple and allow user to
  know about resources available and where to get their exact status from - plan to leverage the CNF model in AAI if they are appropriate
• Long-Term solution should design appropriate CNF Resources in AAI, providing
  only the most important data and relationships about them. - TBD

AAI CNF Model

Note: the following overview came from the Direct CNFO AAI CNF Model. We will start it from here and will finalize the AAI model of ASD-based CNF.

• Create additional AAI Object storing Any CNF Resource in K8s
• This new object (eg. k8sobject) should be related to generic-vnf/vf-module and cloud-region (subresource), using similar relationship matrix as vservers
• Data stored within AAI would be very generic, containing more or less only:
  • Name [string; Primary Key]
  • Group, Version, Kind [strings; Primary Key]
  • Namespace [string; Primary Key]
  • Labels [map[string]string or []string] (depending on AAI capabilities)
  • Annotations [map[string]string or []string ] (depending on AAI capabilities)
  • DetailsReflink [string or object]
    • This field allows AAI Object consumer to specify query toward SO CNF Adapter to get full object data

Simple AAI CNF Model - Jakarta - Initial Model

Note: the following overview came from the Direct CNFO AAI CNF Model. We will start it from here and will finalize the AAI model of ASD-based CNF.

This model was drafted for reference and requires further tuning and agreement. This model needs to be discussed further at the Modeling Subcommittee 

Main assumptions of this model:

• Update existing resources schema (Cloud-Region, Generic-VNF) and/or create CNF counterparts (VF-Module)
• Store Resources definitions about Controllers (eg. Deployments), Compute (Pods, Containers), Storage (PV/PVC), Network (Pod Interfaces, Services) and Configuration resources (eg. ConfigMaps, Secrets).
• Store unclassified resources like CRDs under “Uncategorized” - like object

SO ASDC Controller Handling

ASDC Controller Enhancement

SO Catalog DB Enhancement

VF-VF-Module-Helm Package

• During SDC onboarding, the ASD is mapped to VF, and the DeploymentItems is mapped to Vf-Module
• SO expects ASD VSP onboarding packages has the Native Helm, without Dummy Heat.
• VF is split into multiple vf-modules. each vf-module is dedicated to one Helm package. 
  • each Helm application after instantiation is visible to ONAP as a separate vf-module

Deployment Components

note: the current CNFO; will be changed for ASD-based CNF orchestration

Input Parameter Handling