...
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SO Internal Architecture
The following diagram depicts SO internal architecture for the ASD-based orchestration:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD LCM Restful API
Please refer to the section, ASD LCM RESTful Protocols for SO CNF Manager .
Design and Distribution of ASD Service CSAR - Day 0
The following sequence diagram depicts design and distribution of ASD service CSAR.
PlantUML Macro | ||
---|---|---|
| ||
@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.
Note: use of CDS is TBD.
PlantUML Macro | ||
---|---|---|
| ||
@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
ONAP Component | Description |
---|---|
AAI | Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF-Module |
SDC | VSP, VF and Service Modeling of the ASD-based CNF |
SO | Required for Macro Orchestration using the generic building blocks |
CNF Adapter | |
SDNC | Provides GENERIC-RESOURCE-API for cloud instantiation orchestration via CDS |
Policy | used to store naming policy |
Portal | required to access SDC |
CDS | TBD |
CNFM | |
MultiCloud | TBD |
Runtime Catalog Mgr | |
Helm Artifact Repository | |
Image Artifact Repository |
SO CNF Manager Input Parameter Handling
Gliffy Diagram macroId 3067f9a9-1b62-4a90-8050-575ce73ab04a displayName Helm Data Processing Flow name Helm Data Processing Flow pagePin 6
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
- Orchestrator shall support the capability to use the deployment parameters from ASD for the application or CNF deployment. These deployment parameter values shall correspond to the parameters defined in the “lifecycleParameters” section(s) of the ASD.
- Orchestrator shall support the capability to construct a values file from instance specific parameter values provided at deployment time, and default values supplied in the chart.
- Orchestrator shall support the capability to perform a chart render into concrete K8S resource descriptions.
- Container resource management for determining placement for CNF application on certain K8S cluster(s), orchestrator shall support the capability to parse the workload descriptors and extract those values.
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: Jira server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-1043
Epic
Epic | Description | JIRA | priority | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
SO and its sub-components, CNFM, CNF Adapter, shall support ASD-based CNF lifecycle orchestration | SO and its sub-components, CNFM, CNF Adapter, shall support ASD-based CNF lifecycle orchestration (deployment and configuration) |
| 1 | ||||||||
User Story
User Story | Affected Component | Description | JIRA | Priority |
---|---|---|---|---|
SO shall get the ASD-based CNF package from SDC and store its metadata to SO Catalog DB | SDC Controller, CatalogDB Adapter, CatalogDB | SO shall get the ASD-based CNF package (SDC Service CSAR) from SDC and store its metadata to SO Catalog DB. Pre Condition:
Post Condition:
| 1 | |
| 1 | |||
| 1 | |||
For ASD-based CNF provisioning, SO shall process model info and decide flows | API Handler, RequestDB Adapter, RequestDB, SO BPMN Infra, AAI | SO shall process ASD model info and decide ASD provisioning flows Pre Condition:
Post Condition:
| 2 | |
Task:
| 2.1 | |||
Task:
| 2.2 | |||
Task:
| 2.3 | |||
Task:
| 2.4 | |||
Task:
| 2.5 | |||
SO CNFM shall process ASD-based CNF Lifecycle orchestration | SO CNFM, ASD Repository, Helm Artifact Repository, OOF, AAI, SDNC Adapter, SDNC, CDS, CNF Adapter | SO CNFM shall process ASD-based CNF Lifecycle orchestration Pre Condition:
Post Condition:
Note: PoC, ASD external CPDs will not be handled (TBD) Note: ASD Repository, Helm Artifact Repository, Image Artifact Repository will be handled by another Epic, which is defined in Application Package Distribution | 3 | |
Task: Create SO CNFM and make it available in ONAP
| 3.1 | |||
Task: Support for SO CNFM NBI API Handler
| 3.2 | |||
Task:
| 3.3 | |||
Task:
| 3.4 | |||
Task:
| 3.5 | |||
Task:
| 3.6 | |||
Task: Create SO CNFM Instance Database Management
| 3.7 | |||
Task:
| 3.8 | |||
Task:
| 3.9 | |||
Task:
| 3.10 | |||
Task:
| 3.11 | |||
Task:
| 3.12 | |||
Task:
| 3.13 | |||
SO Client shall send the A La Carte Request for ASD-based CNF orchestration (note: E2E support is out of PoC scope) | SO Client, SO, SO BPMN, CNFM CNF Adapter | SO Client shall send the A La Carte Request for ASD-based CNF orchestration Pre Condition:
Post Condition:
| 4 | |
Task:
| 4.1 | |||
Task:
| 4.2? |
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.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SO Internal Architecture
The following diagram depicts SO internal architecture for the ASD-based orchestration:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Design and Distribution of ASD Service CSAR - Day 0
The following sequence diagram depicts design and distribution of ASD service CSAR.
PlantUML Macro | ||
---|---|---|
| ||
@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.
...
PlantUML Macro | ||
---|---|---|
| ||
@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.
...
- 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
ONAP Component | Description |
---|---|
AAI | Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF-Module |
SDC | VSP, VF and Service Modeling of the ASD-based CNF |
SO | Required for Macro Orchestration using the generic building blocks |
CNF Adapter | |
SDNC | Provides GENERIC-RESOURCE-API for cloud instantiation orchestration via CDS |
Policy | used to store naming policy |
Portal | required to access SDC |
CDS | TBD |
CNFM | |
MultiCloud | TBD |
Runtime Catalog Mgr | |
Helm Artifact Repository | |
Image Artifact Repository |
SO CNF Manager Input Parameter Handling
Gliffy Diagram macroId 3067f9a9-1b62-4a90-8050-575ce73ab04a displayName Helm Data Processing Flow name Helm Data Processing Flow pagePin 7