...
- Support for provisioning ASD-based CNFs using an external K8s Manager
- Instantiate and optionally overwrite the values of an application
- Delete an application and optionally remove all relevant Persistent Volume Claims and Persistent Volumes
- Change application details using the change package function, which allows to change the deployment version of the CNF thru an upgrade or rollback (stretch goal)
- 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.
...
JIRA: Jira server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-1043
Epic
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.
Scope
In Scope
See the Epic and User Stories.
Out of Scope
TBD
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 | ||||||||||
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
Function | Affected Component | User Story & Description | JIRA | Priority | PoC Scope Y/N |
---|---|---|---|---|---|
SO shall get the ASD-based CNF package from SDC and store its metadata to SO Catalog DB |
ASDC 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:
- SO SDC Controller, CatalogDB Adapter and CatalogDB component instances are running and ready to get SDC notifications
Post Condition:
- SO Catalog DB contains the ASD-based CNF package metadata and artifacts
Jira | ||||||
---|---|---|---|---|---|---|
|
|
|
Pre Condition:
Post Condition:
|
| 1 | |||||||||
For ASD-based CNF provisioning, SO shall process model info, decide flows and invoke SO CNFM for AS LCM |
API Handler, RequestDB Adapter, RequestDB, SO BPMN Infra, AAI SO |
Pre Condition:
- SO CatalogDB contains ASD Model metadata
- Resource VF TOSCA.metadata "ASD" entry_definition_type
- SO Client provides parameters based on the ASD lifecycleParameter list
- ASD LCM Restful Protocols will be used for request/response messages and protocols (ASD LCM RESTful Protocols for SO CNF Manager ) and its swagger file (ASD LCM RESTful Protocols for SO CNF Manager)
Post Condition:
- CNF Manager receives requests from SO BPMN Infra and processes the requests
- After the CNF Manager process, SO shall update CNF to AAI
CNFM | Enhance SO API Handler and BPMN Infra workflow(s) for AS LCM
Post Condition:
|
|
| 2 |
- Create & Configures ASD-based CNF workflows
- Create new BPMN workflows for ASD-based CNF workflows
- Design to invoke SO CNF Manager
- Configure SO MacroFlows for ASD-based CNF workflows
- Create new BPMN workflows for ASD-based CNF workflows
Task:
- SO API Handler receives a service (or a la carte) request for ASD-based CNF and stores the request information into the Request DB
- Note: expect no change
Task:
- SO BPMN Infra decomposes Service into VF Resource(s) and per VF resource, SO BPMN process resource handling
- If the VF resource metadata indicates the ASD-based VF, SO shall process ASD-based CNF workflows
SO BPMN Infra shall trigger Create AS Instance workflow(s).
Post Condition:
|
| 2.1 | |||||||||
SO BPMN Infra shall trigger Instantiate AS Instance workflow(s).
Pre Condition:
Post Condition:
|
| 2.2 | |||||||||
SO BPMN Infra shall trigger Delete AS Instance workflow(s).
Pre Condition:
Post Condition:
|
| 2.3 | |||||||||
ONAP Admin Creates Cloud Region(s) and Tenant(s) in AAI Note: use existing AAI admin interfaces (no SO code impact)
|
|
Task:
- SO shall create service instance to AAI
- note: leverage AAI schema service; no code impact
Task:
- SO shall delegate ASD-based CNF orchestration to SO CNFM
- Pass input parameters including ASD reference Id, LifecycleParameter, etc.
- note: until SO CNFM is ready, use no-opt operations as a place holder
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:
- ASD and App onboarding package is stored in the Catalog Repository
- Helm Chart(s) are stored in the Helm Artifact Repository
AAI shall support CRUDQ of ASD-based CNF Resources
- Leverage existing AAI APIs
- Investigate any new AAI APIs for ASD-based CNF Resources (TBD)
Post Condition:
- ASD-based CNF is provisioned by SO CNFM
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
|
|
Task: Create SO CNFM and make it available in ONAP
- Create SO CNFM as an SO sub-component
- Make SO CNFM POD is deployable in OOM
- Register SO CNFM POD to AAI automatically
2.4 | |
In BPMN Infra, create the Create AS Workflow(s) to launch SO CNFM for Create AS
|
|
Task: Support for SO CNFM NBI API Handler
SO CNFM shall support its NBI REST Apis to handle requests from SO.Create SO CNFM NBI API Handler sub-component based on ASD LCM Restful Protocols swagger (
|
Task:
- SO CNFM shall support the capability to process input parameters from SO, and use the deployment parameters from ASD for the CNF deployment. Those deployment parameter values shall correspond to the parameters defined in the "lifecycleParameters" section(s) of the ASD.
Task:
- SO CNFM shall communicate with the ASD Repository to get ASD (descriptor) and artifacts from the ASD repository Manager.
Task:
- SO CNFM shall decompose ASD and get the associated DeploymentItems list
- Get HelmChart references from the DeploymentItems
Task:
- By leveraging the obtained HelmChart references, SO CNFM shall get associated Helm Charts from the Helm Repository Manager.
Task: Create SO CNFM Instance Database Management
- Create SO CNFM Database tables
- Provides Database Access Objects (DAO) for CRUD for SO CNFM
Task:
- SO CNFM shall support the capability to construct a values file from instance specific parameter values from SO and merge the values with default values from ASD Helm Chart values.
- SO CNFM shall store the generated values file for an instance to SO CNFM database
Task:
- SO CNFM shall transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)
Task:
- SO CNFM shall get placement information by passing K8 resources + ASD' + additional data to the Placement component such as OOF.
- Note: Use of OOF could be out-of-PoC-Scope (TBD)
- for PoC, it is allowed to choose predefined K8S Clusters
Task:
- SO CNFM shall make a placement decision based on the decision from the Placement component.
Task:
- Per DeploymentItem, SO CNFM shall send (with cluster id, parameter, cloud artifacts) to the SO CNF Adapter for the connection to K8S plugin(e.g., helm install ...)
- SO CNF Adapter APIs are being studied.
Task:
- SO CNFM shall update the CNF instance to AAI, by leveraging AAI APIs
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:
- SO, CNFM and CNFM Adapter are ready and running
- AAI and SDNC are ready and running
Post Condition:
- CNF Orchestration request is processed and CNF is deployed in K8S
Post Condition:
|
| 2.5 | |||||||||
Enhance Instantiate AS Business Logic (Java code) to launch SO CNFM for Instantiate AS
Post Condition:
|
| 2.6 | |||||||||
Enhance Delete AS Workflow(s) to launch SO CNFM for Delete AS
Post Condition:
|
| 2.7 | |||||||||
SO CNFM shall process ASD-based CNF Lifecycle orchestration | SO CNFM, ASD Repository, Helm Artifact Repository, OOF, AAI, SDNC Adapter, SDNC | Create SO CNFM and make it available in ONAP
Post Condition:
|
|
|
Task:
3 | |
Create ASD LCM REST API Swagger
|
|
- it is out of PoC scope
Task:
- Use of CDS for instance parameter assignment is out of PoC scope (TBD)
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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD LCM Restful API
Please refer to the section, ASD LCM RESTful Protocols for SO CNF Manager .
- Swagger file (ASD LCM RESTful Protocols for SO CNF Manager)
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Component Communication Security
The component communication security will be achieved by leveraging Service Mesh. The external Helm Artifact Repository secure communication is under discussion.
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
...
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
Post Condition:
|
| 3.1 | |||||||||
Create SO CNFM NBI API Handler based on ASD LCM Restful Protocol swagger, no-ops
Post Condition:
|
| 3.2 | |||||||||
Implement Create AS Business Logic in SO CNFM NBI Handler to invoke the Create AS workflows(s) Post Condition:
|
| 3.3 | |||||||||
Implement Instantiate AS Business Logic in SO CNFM NBI Handler to invoke the Instantiate AS workflows(s) Post Condition:
|
| 3.4 | |||||||||
Implement Delete AS Business Logic in SO CNFM NBI Handler to invoke Delete AS workflows(s) Post Condition:
|
| 3.5 | |||||||||
Create SO CNFM Workflow(s) for Create AS
Post Condition:
|
| 3.6 | |||||||||
Create SO CNFM Workflow(s) for Instantiate AS
Post Condition:
|
| 3.7 | |||||||||
Create SO CNFM Workflow(s) for Delete AS
Post Condition:
|
| 3.8 | |||||||||
SO CNFM accesses ASD Registry for getting ASD for Create AS
Post Condition:
|
(moved to London release) | 3.9 | |||||||||
SO CNFM Processes ASD & Retrieves DeploymentItems
Note: for initial PoC, Helm Charts are received from SDC (tbd) Post Condition:
|
| 3.10 | |||||||||
SO CNFM Input Parameter Handling and Instance-Level Helm Charts
Note: enhancedClusterCapbilities input parameter handling is a stretch goal. Post Condition:
|
| 3.11 | |||||||||
Generate and replace values file based on instance variable
Post Condition:
|
(moved to London release) | 3.12 | |||||||||
SO CNFM Transforms Enhanced Helm Charts to K8S Resource Description
Note: this transformation is for a placement decision. If the PoC placement logic is simple or predefined, this could be skipped. Post Condition:
|
(could be not part of the initial PoC) | 3.13 | |||||||||
SO CNFM Gets an AS Placement Decision for a Target K8S Cluster
Post Condition:
|
(moved to London release) | 3.14 | |||||||||
SO CNFM Supports Target K8S Clusters Registration
| TBD (registration is supported, but more to be enhanced in London; moved to London+) | 3.15 | |||||||||
SO CNFM Supports Target K8S Clusters Deregistration
| TBD (moved to London) | 3.16 | |||||||||
SO CNFM Provides a List of Registered K8S Clusters
| TBD (moved to London) | 3.17 | |||||||||
SO CNFM Helm Client Process for AS Deployment
Post Condition:
|
| 3.18 | |||||||||
Note: for the initial PoC, the SO CNF Adapter will not be used. | N/A | ||||||||||
SO CNFM Updates the AS CNF Instance to AAI
Post Condition:
|
| 3.19 | |||||||||
SO Client shall send requests for ASD-based CNF orchestration (note: E2E support is out of PoC scope) | SO Client, SO, SO BPMN, SO CNFM | SO Client shall send requests for ASD-based CNF orchestration to SO
Pre Condition:
Post Condition:
|
|
|
4 |
User Story
...
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:
- SO SDC Controller, CatalogDB Adapter and CatalogDB component instances are running and ready to get SDC notifications
Post Condition:
- SO Catalog DB contains the ASD-based CNF package metadata and artifacts
...
- Task: When SO gets a package notification from DMaaP, SO SDC Controller queries SDC for the ASD-based CNF Service CSAR that embeds the ASD-based CNF Resource VF.
...
- Task: SO distinguishes the ASD-based CNF package based on the package metadata, and stores the ASD-based CNF package metadata and artifacts to SO Catalog DB
...
API Handler,
RequestDB Adapter,
RequestDB,
SO BPMN Infra,
AAI
...
SO shall process ASD model info and decide ASD provisioning flows
Pre Condition:
- SO CatalogDB contains ASD Model metadata
- SO Client provides parameters based on the ASD lifecycleParameter list
Post Condition:
- CNF Manager receives requests from SO BPMN Infra and processes the requests
- After the CNF Manager process, SO shall update CNF to AAI
...
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 supports multiple Helm Charts in CNF packages.
- ASD instance will be decomposed to find its associated deployment item(s).
ASD-Based App Package Type
- The Resource VF(s) in the onboarded Service CSAR will have the following resource main manifest file
- application_name
- application_provider
- release_date_time
- entry_definition_type [ "asd"]
- SO distinguishes the App package based on the "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 | ||||||||
---|---|---|---|---|---|---|---|---|
|
Future NS Consideration
The following diagram depict the NS connection of ASDs.
Gliffy Diagram | ||||
---|---|---|---|---|
|
AS LCM Restful API
Please refer to the section, AS LCM RESTful Protocols for SO CNF Manager .
- Swagger file (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile)
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD LCM Operations
<as_create_instantiate.bpmn example>
Process Sequence
Create and Instantiate AS
- <Preconditions>:
- Registar K8S Cluster(s) to ONAP
- During the registration, SO CNFM creates .kube/{target K8S cluster name}.config file(s)
- <SO BPMN Infra>
- BPMN Infra workflow gets VF Resource TOSCA.meta.
- In there, the entity_defintion_type is found and it is set to "asd", BPMN infra launches the AS LCM Workflow as the above.
- The workflows sends a request for Create AS Identifier to SO CNFM
- <Create an AS Identifier>
- SO CNFM receives the create request (CreateAsRequest) and processes the request and return a response with AsInstance
CreateAsRequest:
asdId
Identifier (UUID) 1 Identifier that identifies the ASD which defines the AS instance to be created. asInstanceDescription
String 0..1 Human-readable description of the AS instance to be created. asInstanceName
String 0..1 Human-readable name of the AS instance to be created. The client passes "asdId" to SO CNFM, so CNFM can query an ASD with the asdId from the ASD Repository
- SO CNFM copies the incoming CreateAsRequest attributes into an AsInstance structure, and persists the AsInstance, which has a connection between the asInstanceId and asdId
- note: SO CNFM will uses the asdId when it queries an ASD from the ASD Repository during the instantiation operation
- When the Create AS instance is successful, SO CNFM returns 200 OK with the AsInstance
- The returned AsInstance contains the asInstanceId
- Subsequent operations uses the asInstanceId; i.e., the Client use the asIstanceId in the REST Api path
- SO CNFM receives the create request (CreateAsRequest) and processes the request and return a response with AsInstance
- <Instantiate an AS>
- BPMN Infra sends an AS instantiate request to SO CNFM with the asInstanceId as follows:
- POST .../as_instances/{asInstanceId}/instantiate (InstantiateAsRequest)
- InstantiateAsRequest
Attribute Name
Data Type
Cardinality
Description
asdExtCpdInputParams
ExtCpdParams
0..N contains ext cpd parameter instance-level value deploymentItems
DeploymentItems 1..N contains lifecycle parameters for deploymentItems additionalParams KeyValuesPairs 0..1 Additional input parameters for the instantiation process (this is a pace holder to hold any additional parameters which are needed by SO CNFM)
- SO CNFM retrieves the corresponding AsInstance from its DB; it is retrieve the "asdId" for the ASD query
- SO CNFM queries an ASD with the asdId from the ASD Repository; caches the retrieved ASD in the memory during the Instantiate operations
- SO CNFM reads thru the ASD DeploymentItems, and per deploymentItems, SO CNFM queries for the associated Helm Chart (1:1) from the Helm Chart Repository
- caches the retrieved Helm Charts in the memory during the Instantiate operations
- SO CNFM reads the deploymentItems.deploymentOrder. Based on the order sequence, SO CNFM processes the deploymentItems one by one
- For each, deployment item,
- SO CNFm creates vf-modules in AAI
- SO CNFM assignes vf-modules in SDNC
- From the InstantiateAsRequest, SO CNFM retrieves the deploymentItems
DeploymentItems
deploymentItemId Identifier 1 Identifies which deploymentItem lifecycleParameterKeyValues
KeyValuesPairs 0..N provides lifecycle parameter keys and values - The lifecycleParameterKeyValues contains a list of customizable attributes (key) in the values.yaml with instance-level values
- From the associated Helm Chart, SO CNFM gets the values.yaml
- SO CNFM creates a new values.yaml, based on the retrieved values.yaml + lifecycleParameterKeyValues
- ==== SO CNFM processes the asdExtCpdInputParam ==== TBD
- SO CNFM performs "helm template " to render K8S resource template(s)
- With the rendered k8S resource template(s), SO CNFM gets a placement decision from the Placement component (e.g., OOF)
- Currently, use of OOF is out of the scope from the initial PoC
- In the initial PoC, a simplified placement function will be used
- Based on the placement decision, SO CNFM determines the target K8S cluster
- Set the Helm command environment to connect to the target K8S cluster
- set .kube/{target K8S cluster name}.config
- SO CNFM invokes "helm install" command with the corresponding Helm Chart and a new values.yaml
- SO CNFM will have a few South-Bound plugin (helm client, CNF Adapter, others)
- in the initial PoC, the helm client will be used
- SO CNFM Helm Client will select a target Kubernetes cluster
- e.g., helm install <release> <chart> --kubeconfig ~/.kubeconfigs/<cluster_name>.kubeconfig
- in the initial PoC, the target cluster is selected by the user and its name will be passed thru the user params (in SO) and additionalParams (in SO-CNFM)
- If successful, SO CNFM update the corresponding vf-module in the AAI
- BPMN Infra sends an AS instantiate request to SO CNFM with the asInstanceId as follows:
- <Postconditions>:
- each POD is a Ready status. This ensures that each POD can serve requests.
- Some of the PODs will not reach the Ready status until a day 1 configuration is applied
- The PODs still need verification of containers with a specific ContainerState
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant SO_Client
participant SO
participant SO_BPMN
participant CNFM
participant AAI
participant SDNC
participant OOF
participant ASD_Catalog_Mgr
participant Helm_Repository |
...
- Create & Configures ASD-based CNF workflows
- Create new BPMN workflows for ASD-based CNF workflows
- Configure SO MacroFlows for ASD-based CNF workflows
...
Task:
- SO API Handler receives a service (or a la carte) request for ASD-based CNF and stores the request information into the Request DB
- Note: expect no change
...
Task:
- SO BPMN Infra decomposes Service into VF Resource(s) and per VF resource, SO BPMN process resource handling
- If the VF resource metadata indicates the ASD-based VF, SO shall process ASD-based CNF workflows
...
Task:
- SO shall create service instance to AAI
- note: leverage AAI schema service; no code impact
...
Task:
- SO shall delegate ASD-based CNF orchestration to SO CNFM
- Pass input parameters including ASD reference Id, LifecycleParameter, etc.
- note: until SO CNFM is ready, use no-opt operations as a place holder
...
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:
- ASD and App onboarding package is stored in the Catalog Repository
- Helm Chart(s) are stored in the Helm Artifact Repository
AAI shall support CRUDQ of ASD-based CNF Resources
- Leverage existing AAI APIs
- Investigate any new AAI APIs for ASD-based CNF Resources (TBD)
Post Condition:
- ASD-based CNF is provisioned by SO CNFM
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
...
Task: Create SO CNFM and make it available in ONAP
- Create SO CNFM as an SO sub-component
- Make SO CNFM POD is deployable in OOM
- Register SO CNFM POD to AAI automatically
...
Task: Support for SO CNFM NBI API Handler
- SO CNFM shall support its NBI REST Apis to handle requests from SO.
- Create SO CNFM NBI API Handler sub-component
- Support CRUDQ REST APIs
...
Task:
- SO CNFM shall support the capability to process input parameters from SO, and use the deployment parameters from ASD for the CNF deployment. Those deployment parameter values shall correspond to the parameters defined in the "lifecycleParameters" section(s) of the ASD.
...
Task:
- SO CNFM shall communicate with the ASD Repository to get ASD (descriptor) and artifacts from the ASD repository Manager.
...
Task:
- SO CNFM shall decompose ASD and get the associated DeploymentItems list
- Get HelmChart references from the DeploymentItems
...
Task:
- By leveraging the obtained HelmChart references, SO CNFM shall get associated Helm Charts from the Helm Repository Manager.
...
Task: Create SO CNFM Instance Database Management
- Create SO CNFM Database tables
- Provides Database Access Objects (DAO) for CRUD for SO CNFM
...
Task:
- SO CNFM shall support the capability to construct a values file from instance specific parameter values from SO and merge the values with default values from ASD Helm Chart values.
- SO CNFM shall store the generated values file for an instance to SO CNFM database
...
Task:
- SO CNFM shall transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)
...
Task:
- SO CNFM shall get placement information by passing K8 resources + ASD' + additional data to the Placement component such as OOF.
- Note: Use of OOF could be out-of-PoC-Scope (TBD)
- for PoC, it is allowed to choose predefined K8S Clusters
...
Task:
- SO CNFM shall make a placement decision based on the decision from the Placement component.
...
Task:
- Per DeploymentItem, SO CNFM shall send (with cluster id, parameter, cloud artifacts) to the SO CNF Adapter for the connection to K8S plugin(e.g., helm install ...)
- SO CNF Adapter APIs are being studied.
...
Task:
- SO CNFM shall update the CNF instance to AAI, by leveraging AAI APIs
...
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:
- SO, CNFM and CNFM Adapter are ready and running
- AAI and SDNC are ready and running
Post Condition:
- CNF Orchestration request is processed and CNF is deployed in K8S
...
Task:
- Provide CNF instance input parameters, based on the lifecycleParameters from the ASD DeploymentItem
- Provide asdExtCpd inputParamMappings for CNF deployment
- it is out of PoC scope
...
Task:
- Use of CDS for instance parameter assignment is out of PoC scope (TBD)
...
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-Based PACKAGECNF DistributionInstantiation hnote over SDC : SDC supports ASD-based Service CSARSO_Client -> SO : Create Service DesignerSO -> SDCSO_BPMN : OnboardingProcess ASDand AppDecompose PackageService SDCSO_BPMN --> SDCAAI : OnboardsCreate ASDService App Package and\ngenerates Service CSARInstance opt Service-Level Homing SDCSO_BPMN -> SOOOF : DistributeHoming Service CSARInformation (optional for PoC) SDCOOF -> AAISO_BPMN : Distribute Service CSAR Receive Homing Information (optional for PoC) end SDCSO_BPMN --> K8SSO_ClusterBPMN : DistributeProcess ServiceModel CSAR end group K8S Cluster Admin hnote over Admin : Admin accesses K8S ClusterInfo & Decide flows AdminSO_BPMN -> K8S_ClusterCNFM : Create/Update/Configure K8S ClusterDelegate Resource Orchestration,\npass input parameters AdminCNFM -> AAIASD_Catalog_Mgr : Add/Register K8S ClusterGet ASD AAICNFM --> AAIHelm_Repository : Get Addassociated theHelm tenantCharts AAICNFM --> K8S_PluginCNFM : 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 ASDProcess and decompose ASD and DeploymentItems\n(VF & Vf-Modules) CNFM --> CNFM : get DeploymentItem order and create a sequence list CNFM --> CNFM : execute each deployment item by following the sequence order loop CNFM -> AAI : Create vf-module CNFM -> SDNC : Assign vf-module CNFM --> CNFM : Get AsInstance LifecycleParameterMetadata from the request CNFM --> CNFM : Get the corresponding Helm Chart CNFM --> CNFM : Create a new values file by replacing the values file from the Helm Chart with LifecycleParameterMetadata CNFM --> CNFM : generate K8S resource (e.g., helm template) based on the Helm Chart plus a new custom values file CNFM -> Helm_RepositoryOOF : Getget associateda Helm Charts placement decision (for PoC, returns a predefined K8S cluster name) CNFM --> CNFM: :set Processkube andconfig decomposeenvironment ASDfor and DeploymentItems\n(VF & Vf-Modules)the target K8S Cluster CNFM --> CNFMK8S_Cluster : getinvoke DeploymentItemHelm orderInstall andwith createa acustom sequencevalues list loopfile CNFM -> AAI : CreateUpdate vf-module end 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 @endumlend @enduml |
AS LCM APIs
Create an AS Identifier
In order for an application (CNF) to be eligible for instantiation, a CNF identifier must be created to identify the application service as a unique instance.
An AS instance supports multiple deployment items (helm charts). So, the AS instance id could be used for helm release names as the prefix.
Query AS Instance Identifiers
To list all AS instances, make a GET request to SO CNFM.
GET .../aslcm/v1/as_instances
Query an AS instance by Instance ID
To query a specific AS instance by its instance ID, make a GET request to SO CNFM.
GET .../aslcm/v1/as_instances/{asInstanceId}
Instantiate an AS
- To instantiate an AS, make a poST request to SO CNFM. The target cluster name is included in the requrest parameter.
POST .../as_instances/{asInstanceId}/instantiate
- if some of the parameters required for instantiation are complex and cannot fit into the additionalParams section of the JSON request body (TBD).
Upgrading an AS
This operation is referred to as the changing of an AS package.
POST .../as_instances/{asInstanceId}/change_aspkg
Terminate an AS Instance
This operation terminates an AS instance.
POST .../as_instances/{asInstnaceId}/terminate (TerminateAsRequest)
Note: for PoC, GRACEFUL termination type is not supported.
Delete an AS Identifier
This operation deletes an AS Identifier.
DELETE .../as_instances/{as_instanceId}
Note: optionally, Delete an AS Identifier could clean up resources of an AS Instance, e.g., Persistent Volumes (PVs)
The Delete operation may need to update AAI.
===========
Register K8S Clusters
This adds an ability for CNFM to register container managers like Kubernetes. that will allow to instantiate and deploy containerized CNFs.
Note: Kubernetes is advanced and commonly used CISM as of now, but in the future, adding other CISM types could be considered. for now Kubernetes is a reference implementation.
In order to make CNFM to be able to operate K8S Clusters we need introduce K8S Cluster registration, deregistration and querying features.
- As a user I want to be able to register and list CISM Cluster, which is already deployed.
- As a user I want to name the CISM Cluster and select it’s type.
- As for main information source of k8s cluster type configuration I want to use a kubectl configuration file to feed authentication information and connectivity point information.
- As a user I want to modify and transform information upon uploading (upload certificates, change or select username and credentials).
- As a user I want to be able to query all stored information for clusters both individual cluster information and filtered list by criteria(ie name, type, status, etc).
Information needed for registration
- CISM Cluster Name
- CISM Cluster type (Kubernetes)
- CISM Cluster Server URL
- Username to access API
- Option to populate connectivity details by uploading kubeconfig file
Kubeconfig contains connectivity details for the K8s cluster(hostname, port, apiRoot), which includes authentication details, too
- Certificate Authority
========
To instantiate an AS on an non-ONAP K8S cluster, a cluster configuration file that is specific to the cluster must be uploaded.
To add a cluster configuration file of a cluster, create a POST request .../aslcm/v1/clusterconfigs will be performed.
- CNFM receives the clusterconfigs info and creates a cluster configuration file (cluster name + "." + "config" to the ./kube directory.
The kubectl configuration file is used to the body of the request to define external K8S clusters.
The cluster configuration file for a particular cluster must be retrieved from the cluster administrator.
The Cluster configuration file pre-requisities are:
- It must start with an alphanumberic character
- It can only contain alpahnumberic characters, dashes (-_, or underscores (_)
- It must end with .config
Should the cluster configuration file change for any reason, e.g., CA certificate rotation on the target cluster or client key expires, then the cluster file registered in SO CNFM/AAI shall need to be updated.
The target cluster server and port must be reachable from the SO CNFM.
- to verify the connectdion to the target cluster, run the following command from the ONAP K8S cluster
- kubectl --kubeconfig ${PATH_TO_TARGET_CLUSTER_CONFIGURATION_FILE} get namespaces
Deregister K8S Clusters
To remove a cluster configruation file, create a DELETE request. .../aslcm/v1/clusterconfig/{configName}
The configName would include the K8S Cluster name as the file prefix
CNFM will remove the "configName" + "." + "config" file from the .kube directory.
The command returns the HTTP status code 204 No Content
List Registered K8S Clusters (checking if AAI can be used)
To get details about registered clusters, create a GET request .../aslcm/v1/clusterconfigs
The API returns a paginated response, but if a customized response is needed, additional parameters for page, size, sor and filtering could be applied.
Helm Command Support
The Helm library uses the Kubernetes client library to communicate with Kubernetes. Currently, the library uses REST+JSON. It stores information in Secrets located inside of Kubernetes; i.e., it does not need its own database.
- Helm Install
- Helm Uninstall
- Helm Upgrade
Note: Helm is a package manager. Managing how instances (helm release) of packages are run in an environment is a separate concern. For Helm release handling, we are considering additional tools and mechanisms.
Component Communication Security
The component communication security will be achieved by leveraging Service Mesh. The external Helm Artifact Repository secure communication is under discussion.
Design and Distribution of ASD Service CSAR - Day 0
The following sequence diagram depicts design and distribution of ASD service CSAR, based on CNFO. This sequence could be changed.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant Designer
participant Admin
participant SDC
participant Catalog_Manager
participant Helm_Registry
participant Image_Registry
participant SO_Client
participant SO
participant CNFM
participant CNF_Adapter
participant AAI
participant K8S_Cluster
autonumber
group ASD App 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 Resource VF(s) and Service CSAR
SDC -> SO : Distribute Service CSAR
SDC -> AAI : Distribute Service CSAR
end
group ASD Helm Chart and Image Distribution
hnote over Catalog_Manager : ASD, Helm Chart and Image Distribution
Catalog_Manager -> SDC : Get ASD App Artifacts
Catalog_Manager -> Helm_Registry : push Helm Charts
Catalog_Manager -> Image_Registry : push Images
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
Admin -> AAI : Add the tenant
K8S_Cluster -> AAI : Auto Discovery (optional)
Admin -> CNFM : POST Connectivity Info (Kubeconfig file)
end
@enduml |
Instantiation of ASD Service CSAR - Day 1
The following sequence diagram depicts instantiation of ASD-based CNF.
Option A: use Helm Command:
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant SO_Client
participant SO
participant SO_BPMN
participant CNFM
participant AAI
participant SDNC
participant OOF
participant ASD_Catalog_Mgr
participant Helm_Repository
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
CNFM --> CNFM : execute each deployment item by following the sequence order
loop
CNFM -> AAI : Create vf-module
CNFM -> SDNC : Assign vf-module
CNFM --> CNFM : Get AsInstance LifecycleParameterMetadata from the request
CNFM --> CNFM : Get the corresponding Helm Chart
CNFM --> CNFM : Create a new values file by replacing the values file from the Helm Chart with LifecycleParameterMetadata
CNFM --> CNFM : generate K8S resource (e.g., helm template) based on the Helm Chart plus a new custom values file
CNFM -> OOF : get a placement decision (for PoC, OOF is not used; returns a predefined K8S cluster name)
CNFM --> CNFM: set kube config environment for the target K8S Cluster
CNFM --> K8S_Cluster : invoke Helm Install with a custom values file
CNFM -> AAI : Update vf-module
end
end
@enduml |
Option B: use of CNF Adapter (this is not part of initial PoC)
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 |
Tenant Support
The Tenant support will be realized by Kubernetes cluster, namespace, node and container. Initially, namespace can be used to restrict API access, to constrain resource usage and to restrict what containers are allowed to do.
Assumption & Requirements (from cloud.google.com)
source: https://cloud.google.com/kubernetes-engine/docs/best-practices/enterprise-multitenancy
The best practices in this guide are based on a multi-tenant use case for an enterprise environment, which has the following assumptions and requirements:
- The organization is a single company that has many tenants (two or more application/service teams) that use Kubernetes and would like to share computing and administrative resources.
- Each tenant is a single team developing a single workload.
- Other than the application/service teams, there are other teams that also utilize and manage clusters, including platform team members, cluster administrators, auditors, etc.
- The platform team owns the clusters and defines the amount of resources each tenant team can use; each tenant can request more.
- Each tenant team should be able to deploy their application through the Kubernetes API without having to communicate with the platform team.
- Each tenant should not be able to affect other tenants in the shared cluster, except via explicit design decisions like API calls, shared data sources, etc.
Access Control
TBD
Network Policies
TBD
Resource Quotas
TBD
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
Use of AAI Model K8S Resource Object
We are considering reuse of AAI K8S Resource Object, which was designed for CNFO.
Use of AAI Model K8S Resource Object Relations
We are considering reuse of AAI K8S Resource Object Relations (TBD)
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 76