You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 93 Next »

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: REQ-1043 - Getting issue details... STATUS

Epic

EpicDescriptionJIRApriority
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)

SO-3808 - Getting issue details... STATUS

1








User Story

User StoryAffected ComponentDescriptionJIRAPriority
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:

  • 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

SO-3839 - Getting issue details... STATUS

1
  • 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.

1
  • 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

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:

  • 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

SO-3840 - Getting issue details... STATUS

2
Task: 
  • Create & Configures ASD-based CNF workflows
    • Create new BPMN workflows for ASD-based CNF workflows
    • Configure SO MacroFlows for ASD-based CNF workflows

2.1

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

2.2

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

2.3

Task:

  • SO shall create service instance to AAI
    • note: leverage AAI schema service; no code impact

2.4

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

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:

  • 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 

SO-3841 - Getting issue details... STATUS

3

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

3.1

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

3.2

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.

3.3

Task:

  • SO CNFM shall communicate with the ASD Repository to get ASD (descriptor) and artifacts from the ASD repository Manager.

3.4

Task:

  • SO CNFM shall decompose ASD and get the associated DeploymentItems list
    • Get HelmChart references from the DeploymentItems

3.5

Task:

  • By leveraging the obtained HelmChart references, SO CNFM shall get associated Helm Charts from the Helm Repository Manager.

3.6

Task: Create SO CNFM Instance Database Management

  • Create SO CNFM Database tables
  • Provides Database Access Objects (DAO) for CRUD for SO CNFM

3.7

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

3.8

Task:

  • SO CNFM shall transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)

3.9

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

3.10

Task:

  • SO CNFM shall make a placement decision based on the decision from the Placement component.

3.11

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. 

3.12

Task:

  • SO CNFM shall update the CNF instance to AAI, by leveraging AAI APIs

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: 

  • 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

SO-3842 - Getting issue details... STATUS

4

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

4.1

Task:

  • Use of CDS for instance parameter assignment is out of PoC scope (TBD)

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.

ASD LCM Orchestration-Jakarta


SO Internal Architecture

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

SO ASD Orchestration

ASD LCM Restful API

Please refer to the section, ASD LCM RESTful Protocols for SO CNF Manager .

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. ASD Onboarding Designer Designer Admin Admin SDC SDC SO_Client SO_Client SO SO CNFM CNFM CNF_Adapter CNF_Adapter K8S_Plugin K8S_Plugin AAI AAI K8S_Cluster K8S_Cluster ASD PACKAGE Distribution SDC supports ASD-based Service CSAR 1Onboarding ASD App Package 2Onboards ASD App Package andgenerates Service CSAR 3Distribute Service CSAR 4Distribute Service CSAR 5Distribute Service CSAR K8S Cluster Admin Admin accesses K8S Cluster 6Create/Update/Configure K8S Cluster 7Add/Register K8S Cluster 8Add the tenant 9Post Connectivity Info (Kubconfig file)

Instantiation of ASD Service CSAR - Day 1

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

Note: use of CDS is TBD.


ASD-CNF Instantiation SO_Client SO_Client SO SO SO_BPMN SO_BPMN CNFM CNFM AAI AAI SDNC SDNC CDS CDS OOF OOF ASD_Catalog_Mgr ASD_Catalog_Mgr Helm_Repository Helm_Repository CNF_Adapter CNF_Adapter K8S_Plugin K8S_Plugin K8S_Cluster K8S_Cluster ASD-Based CNF Instantiation 1Create Service 2Process and Decompose Service 3Create Service Instance opt[Service-Level Homing] 4Homing Information (optional for PoC) 5Receive Homing Information (optional for PoC) 6Process Model Info & Decide flows     7Delegate Resource Orchestration,pass input parameters 8Get ASD 9Get associated Helm Charts 10Process and decompose ASD and DeploymentItems(VF & Vf-Modules) 11get DeploymentItem order and create a sequence list loop 12Create vf-module 13Assign vf-module 14Assign vf-module 15Build RB Profile 16Assign result 17vf-module assigned 18Assign vf-module 19RB Profile (Helm enrichment) 20vf-module assigned 21Update vf-module 22Dry run for getting K8S resource(Vf-Module) 23get Homing Information per resource(Vf-Module) 24Create vf-module in K8S 25Create vf-module in K8S(RB Instance) 26Install Helm Chart 27K8S Resource Instance Status 28vf-module in K8S created 29Update vf-module

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 ComponentDescription
AAIRequired for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF-Module
SDCVSP, VF and Service Modeling of the ASD-based CNF
SORequired for Macro Orchestration using the generic building blocks
CNF Adapter
SDNCProvides GENERIC-RESOURCE-API for cloud instantiation orchestration via CDS
Policyused to store naming policy
Portalrequired to access SDC
CDSTBD
CNFM
MultiCloudTBD
Runtime Catalog Mgr
Helm Artifact Repository
Image Artifact Repository

SO CNF Manager Input Parameter Handling


Helm Data Processing Flow

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: REQ-1043 - Getting issue details... STATUS

Epic

EpicDescriptionJIRApriority
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)

SO-3808 - Getting issue details... STATUS

1








User Story

User StoryAffected ComponentDescriptionJIRAPriority
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:

  • 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

1
  • 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.

1
  • 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

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:

  • 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

2
Task: 
  • Create & Configures ASD-based CNF workflows
    • Create new BPMN workflows for ASD-based CNF workflows
    • Configure SO MacroFlows for ASD-based CNF workflows

2.1

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

2.2

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

2.3

Task:

  • SO shall create service instance to AAI
    • note: leverage AAI schema service; no code impact

2.4

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

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:

  • 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 


3

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

3.1

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

3.2

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.

3.3

Task:

  • SO CNFM shall communicate with the ASD Repository to get ASD (descriptor) and artifacts from the ASD repository Manager.

3.4

Task:

  • SO CNFM shall decompose ASD and get the associated DeploymentItems list
    • Get HelmChart references from the DeploymentItems

3.5

Task:

  • By leveraging the obtained HelmChart references, SO CNFM shall get associated Helm Charts from the Helm Repository Manager.

3.6

Task: Create SO CNFM Instance Database Management

  • Create SO CNFM Database tables
  • Provides Database Access Objects (DAO) for CRUD for SO CNFM

3.7

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

3.8

Task:

  • SO CNFM shall transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)

3.9

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

3.10

Task:

  • SO CNFM shall make a placement decision based on the decision from the Placement component.

3.11

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. 

3.12

Task:

  • SO CNFM shall update the CNF instance to AAI, by leveraging AAI APIs

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: 

  • 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

4

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

4.1

Task:

  • Use of CDS for instance parameter assignment is out of PoC scope (TBD)

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.

ASD LCM Orchestration-Jakarta


SO Internal Architecture

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

SO ASD Orchestration

Design and Distribution of ASD Service CSAR - Day 0

The following sequence diagram depicts design and distribution of ASD service CSAR. ASD Onboarding Designer Designer Admin Admin SDC SDC SO_Client SO_Client SO SO CNFM CNFM CNF_Adapter CNF_Adapter K8S_Plugin K8S_Plugin AAI AAI K8S_Cluster K8S_Cluster ASD PACKAGE Distribution SDC supports ASD-based Service CSAR 1Onboarding ASD App Package 2Onboards ASD App Package andgenerates Service CSAR 3Distribute Service CSAR 4Distribute Service CSAR 5Distribute Service CSAR K8S Cluster Admin Admin accesses K8S Cluster 6Create/Update/Configure K8S Cluster 7Add/Register K8S Cluster 8Add the tenant 9Post Connectivity Info (Kubconfig file)

Instantiation of ASD Service CSAR - Day 1

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

Note: use of CDS is TBD.


ASD-CNF Instantiation SO_Client SO_Client SO SO SO_BPMN SO_BPMN CNFM CNFM AAI AAI SDNC SDNC CDS CDS OOF OOF ASD_Catalog_Mgr ASD_Catalog_Mgr Helm_Repository Helm_Repository CNF_Adapter CNF_Adapter K8S_Plugin K8S_Plugin K8S_Cluster K8S_Cluster ASD-Based CNF Instantiation 1Create Service 2Process and Decompose Service 3Create Service Instance opt[Service-Level Homing] 4Homing Information (optional for PoC) 5Receive Homing Information (optional for PoC) 6Process Model Info & Decide flows     7Delegate Resource Orchestration,pass input parameters 8Get ASD 9Get associated Helm Charts 10Process and decompose ASD and DeploymentItems(VF & Vf-Modules) 11get DeploymentItem order and create a sequence list loop 12Create vf-module 13Assign vf-module 14Assign vf-module 15Build RB Profile 16Assign result 17vf-module assigned 18Assign vf-module 19RB Profile (Helm enrichment) 20vf-module assigned 21Update vf-module 22Dry run for getting K8S resource(Vf-Module) 23get Homing Information per resource(Vf-Module) 24Create vf-module in K8S 25Create vf-module in K8S(RB Instance) 26Install Helm Chart 27K8S Resource Instance Status 28vf-module in K8S created 29Update vf-module

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 ComponentDescription
AAIRequired for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF-Module
SDCVSP, VF and Service Modeling of the ASD-based CNF
SORequired for Macro Orchestration using the generic building blocks
CNF Adapter
SDNCProvides GENERIC-RESOURCE-API for cloud instantiation orchestration via CDS
Policyused to store naming policy
Portalrequired to access SDC
CDSTBD
CNFM
MultiCloudTBD
Runtime Catalog Mgr
Helm Artifact Repository
Image Artifact Repository

SO CNF Manager Input Parameter Handling


Helm Data Processing Flow

  • No labels