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

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

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 configuration)	SO-3808 - Getting issue details... STATUS	1

User Story

Function	Affected Component	User Story & Description	JIRA	Priority
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. SO ASDC Controller handles ASD-based CNF Service CSAR onboarding 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. SO Catalog DB Handling for ASD-based CNF packages 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 Resource VF TOSCA.metadata will have the "ASD" entity_definition_type 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

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 CNFM	Enhance SO API Handler and BPMN Infra workflow(s) for AS LCM SO endpoints shall be enhanced for handle ASD-based CNF LCM SO API Handler receives a service request for ASD-based CNF and stores the request information into the Request DB Thru workflow(s) mapping, SO API Handler invokes BPMN Infra workflows (e.g., Workflow_BB Execute) Configure SO MacroFlows configurations for invoking BPMN Infra workflows SO BPMN Infra decomposes Service into VF Resource(s), and per VF resource, SO BPMN Infra process AS resource handling If the VF resource metadata indicates the ASD-based VF (e.g., entity_definition_type='ASD' or 'asd'), SO shall process ASD-based CNF workflows SO Create Service Instance to AAI SO shall create service instance to AAI, leveraging existing AAI schema service Post Condition: SO API Handler receives SO requests and invoke BPMN Infra Workflow(s) for AS LCM.	SO-3905 - Getting issue details... STATUS	2
		SO BPMN Infra shall trigger Create AS Instance workflow(s). Enhance BPMN Infra workflow(s) to add the Create AS workflow(s) for Create AS BPMN Infra workflow(s) shall launch the Create AS workflow(s) Create AS workflow(s) invokes SO CNFM thru AS LCM Restful Create AS APIs Post Condition: SO CNFM Create AS NBI is invoked for Create AS	SO-3840 - Getting issue details... STATUS	2.1
		SO BPMN Infra shall trigger Instantiate AS Instance workflow(s). BPMN Infra main workflow(s) shall launch the enhanced AS workflow(s) for Instantiate AS Enhance BPMN Infra AS workflow(s) to enhance/add the Instantiate AS service task(s) for Instantiate AS Extract required user parameters from the Service request body add service task(s) to invoke SO CNFM thru Instantiate AS Instantiate AS operation message pattern is async. Add a subsequent service task will get acknowledgement or error Add next Instantiate AS service task(s) to query for the Instantiate AS status Pre Condition: Create AS Workflows have been performed Post Condition: Instantiate AS service task(s) invoke Instantiate AS operations and get acknowledgment/error and get the Instantiate AS status	SO-3881 - Getting issue details... STATUS	2.2
		SO BPMN Infra shall trigger Delete AS Instance workflow(s). Enhance BPMN Infra workflow(s) to add the Delete AS workflow(s) for Delete AS BPMN Infra workflow(s) shall launch the Delete AS workflow(s) Delete AS workflow(s) invokes SO CNFM thru AS LCM Restful Instantiate AS APIs Pre Condition: Create/Instantiate AS Workflows have been performed Post Condition: SO CNFM Delete AS NBI is invoked for Delete AS	SO-3885 - Getting issue details... STATUS	2.3
		ONAP Admin Creates Cloud Region(s) and Tenant(s) in AAI Note: use existing AAI admin interfaces (no SO code impact) ONAP Admin creates new cloud region(s) and tenant(s) in AAI Each K8S cluster is registered as a cloud-region in AAI, but K8S cluster connectivity info will not be stored in AAI In CNFO, MultiCloud K8S Plugin will hold the K8S connectivity info In our case, SO CNFM will hold the K8S connectivity info See the SO CNFM register/deregister K8S clusters operations for more details note: CNFO AAI Model K8S Resource Object Relations	SO-3882 - Getting issue details... STATUS	2.4
		In BPMN Infra, create the Create AS Workflow(s) to launch SO CNFM for Create AS SO BPMN Infra shall delegate ASD-based CNF orchestration to SO CNFM Extract required parameters from the Service request body With the Service request input parameters, formulate request messages by conforming to ASD LCM Restful Protocols (AS LCM RESTful Protocols for SO CNF Manager ) and its swagger file (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile) for CreateASRequest, get: asdId asInstanceName asInstanceDescription As a SO CNFM client, use the following client operations to invoke SO CNFM AS LCM RESTful Protocols for SO CNF Manager#CreateASInstanceResource Post Condition: SO CNFM Create AS is invoked and AsInstance object is returned if the operation is successful; otherwise, an error will be returned	SO-3883 - Getting issue details... STATUS	2.5
		Enhance Instantiate AS Business Logic (Java code) to launch SO CNFM for Instantiate AS SO BPMN Infra shall delegate ASD-based CNF orchestration to SO CNFM Extract required parameters from the Service request body With the Service request input parameters, formulate request messages for Instantiate AS by conforming to ASD LCM Restful Protocols (AS LCM RESTful Protocols for SO CNF Manager ) and its swagger file (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile) for InstantiateAsRequest, get: asdExtCpdInputParams deploymentItems additionalparams As a SO CNFM client, use the following client operations to invoke SO CNFM AS LCM RESTful Protocols for SO CNF Manager#InstantiateASInstanceResource Post Condition: SO CNFM Instantiate AS is invoked and the request is accepted	SO-3884 - Getting issue details... STATUS	2.6
		Enhance Delete AS Workflow(s) to launch SO CNFM for Delete AS SO BPMN Infra shall delegate ASD-based CNF orchestration to SO CNFM Extract required parameters from the Service request body With the Service request input parameters, formulate request messages by conforming to ASD LCM Restful Protocols (AS LCM RESTful Protocols for SO CNF Manager ) and its swagger file (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile) for Delete AS, get: asInstanceId as a parameter As a SO CNFM client, use the following client operations to invoke SO CNFM AS LCM RESTful Protocols for SO CNF Manager#DeleteASInstanceResource Post Condition: SO CNFM Delete AS is invoked and the AS instance and associated resource are deleted	SO-3886 - Getting issue details... STATUS	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 Create SO CNFM as an SO sub-component, with NBI, Business Logic and SouthBound Plugin for 1) Helm Client or ~~2) CNF Adapter~~ In this PoC, the Helm Client SouthBound Plugin will be used use of the CNF Adapter is a future consideration. Make SO CNFM POD is deployable in OOM Register SO CNFM POD to AAI automatically to be recognized Post Condition: SO CNFM is available	SO-3888 - Getting issue details... STATUS	3
		Create ASD LCM REST API Swagger Create SO CNFM REST API swagger, based on the ASD LCM Restful API, AS LCM RESTful Protocols for SO CNF Manager and Swagger file (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile) Note: the swagger file is created and it needs to be refined further Post Condition: Swagger file is ready for SO CNM NBI	SO-3889 - Getting issue details... STATUS	3.1
		Create SO CNFM NBI API Handler based on ASD LCM Restful Protocol swagger, no-ops 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 (AS LCM RESTful Protocols for SO CNF Manager#SwaggerFile) Support the following service operations: AS LCM RESTful Protocols for SO CNF Manager#CreateASInstanceResource AS LCM RESTful Protocols for SO CNF Manager#InstantiateASInstanceResource AS LCM RESTful Protocols for SO CNF Manager#DeleteASInstanceResource For multiple operator K8S Cluster support, the following operations are supported (stretch goal) AS LCM RESTful Protocols for SO CNF Manager#RegisterK8SClusters AS LCM RESTful Protocols for SO CNF Manager#DeregisterK8SClusters Note: for the initial PoC, registration and deregistration could be out of scope (stretch goal) Post Condition: SO CNFM NBI API Handler is ready to receive SO BPMN Infra requests, with no-ops	SO-3890 - Getting issue details... STATUS	3.2
		Implement Create AS Business Logic in SO CNFM NBI Handler to invoke the Create AS workflows(s) Post Condition: SO CNFM NBI Handler is able to invoke Create AS workflow(s)	SO-3893 - Getting issue details... STATUS	3.3
		Implement Instantiate AS Business Logic in SO CNFM NBI Handler to invoke the Instantiate AS workflows(s) Post Condition: SO CNFM NBI Handler is able to invoke Instantiate AS workflow(s)	SO-3904 - Getting issue details... STATUS	3.4
		Implement Delete AS Business Logic in SO CNFM NBI Handler to invoke Delete AS workflows(s) Post Condition: SO CNFM NBI Handler is able to invoke Delete AS workflow(s)	SO-3894 - Getting issue details... STATUS	3.5
		Create SO CNFM Workflow(s) for Create AS Create AS Service Task(s) will invoke corresponding Create AS Java-based business logic. Post Condition: Workflow(s) for Create AS is ready	SO-3891 - Getting issue details... STATUS	3.6
		Create SO CNFM Workflow(s) for Instantiate AS Instantiate AS Service Task(s) will invoke corresponding Instantiate AS Java-based business logic. add vf module and k8s resource obj in A&AI Post Condition: Workflow(s) for Instantiate AS is ready	SO-3906 - Getting issue details... STATUS	3.7
		Create SO CNFM Workflow(s) for Delete AS Delete AS Service Task(s) will invoke corresponding Delete AS Java-based business logic. Post Condition: Workflow(s) for Delete AS is ready	SO-3892 - Getting issue details... STATUS	3.8
		SO CNFM accesses ASD Registry for getting ASD for Create AS SO CNFM shall communicate with the ASD Registry to get ASD (descriptor) and artifacts from the ASD Registry Manager Use the asdId (which is received during the Create AS operation) to retrieve an ASD Get ASD from the ASD Registry thru the ASD Registry Manager APIs (see the note) ~~e.g., GET /api/asds/<name>~~ Note: for initial PoC, it is possible ASD is received from SDC Post Condition: SO CNFM receives a selected ASD	SO-3897 - Getting issue details... STATUS (moved to London release)	3.9
		SO CNFM Processes ASD & Retrieves DeploymentItems SO CNFM shall decompose the received ASD and get the associated DeploymentItems lists Get HelmChart references from the DeploymentItems use the 'artifactId' attribute for Helm chart references Get the corresponding Helm Charts from the Helm Registry e.g., helm chart pull <artifactId> Note: for initial PoC, Helm Charts are received from SDC (tbd) Post Condition: SC CNFM collects all the associated Helm Charts.	SO-3898 - Getting issue details... STATUS	3.10
		SO CNFM Input Parameter Handling and Instance-Level Helm Charts SO CNFM shall process input parameters that came thru SO BPMN Infra, by conforming to ASD LCM Restful Protocols, such as: DeploymentItem parameters The key value pairs, which is to override the default values.yaml ExtCpdParams parameters The parameters will be used to resolve input in the Helm Charts For the initial PoC, only loadbalancerIP or externalIPs will be supported SO CNFM shall support the capability to construct custom values file(s), by: applying Instance-level input parameter parameter values which came thru SO enhancing helm charts with resolved input parameter values generating new custom values file(s), based on the DeploymentItem parameter values which came thru SO SO CNFM shall store the generated helm charts and/or values files to the SO CNFM database Note: enhancedClusterCapbilities input parameter handling is a stretch goal. Post Condition: Based on input parameters, ASD and DeploymentItems, a new instance-level Helm Charts will be built.	SO-3899 - Getting issue details... STATUS	3.11
		Generate and replace values file based on instance variable SO CNFM generates and replace values files based on instance parameter values Post Condition: Helm Chart value files are replaced and ready to use for deployment.	SO-3900 - Getting issue details... STATUS (moved to London release)	3.12
		SO CNFM Transforms Enhanced Helm Charts to K8S Resource Description SO CNFM shall transform enhanced Helm charts to K8S resource description (e.g., helm template or helm install --dry-run) to verify Helm charts and examine potential K8S resource requirements Note: this transformation is for a placement decision. If the PoC placement logic is simple or predefined, this could be skipped. Post Condition: K8S resource description is ready for feeding into placement.	SO-3901 - Getting issue details... STATUS (could be not part of the initial PoC)	3.13
		SO CNFM Gets an AS Placement Decision for a Target K8S Cluster With the generated K8S resources description(s), for each K8S resource description (per Helm chart), SO CNFM shall get a placement decision based on the decision from the Placement component. In the initial PoC, a pre-selected K8S cluster (selected by the client) can be used. Use of the enhancedClusterCapabilities is a stretch goal. In the future, SO CNFM will do the following functions: ASD enhancedClusterCapabilities attribute will be used to for K8S Cluster selection requirements, SO CNFM will query for K8S clusters for capabilities. OOF can be used for this SO CNFM will choose a proper/capable K8S cluster. Post Condition: SO CNFM selects a target K8S cluster	SO-3896 - Getting issue details... STATUS (moved to London release)	3.14
		SO CNFM Supports Target K8S Clusters Registration SO CNFM shall support Registration of K8S cluster(s) 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. SO CNFM receives the clusterconfigs info and creates a cluster configuration file (cluster name + "." + "config" to the ./kube directory. Note: The cluster configuration file for a particular cluster must be retrieved from the cluster administrator. The Cluster configuration file pre-requisites are: It must start with an alphanumeric character It can only contain alphanumeric 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. Verify the connection to the target cluster	TBD (registration is supported, but more to be enhanced in London; moved to London+)	3.15
		SO CNFM Supports Target K8S Clusters Deregistration 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.	TBD (moved to London)	3.16
		SO CNFM Provides a List of Registered K8S Clusters 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, or and filtering could be applied.	TBD (moved to London)	3.17
		SO CNFM Helm Client Process for AS Deployment For the initial PoC, the Helm Client will be used as a SO CNF Southbound plugin for interfacing with K8S Cluster(s) An ASD can contain multiple DeploymentItems (which are corresponding Helm Charts). To determine the order of Helm Chart executions, the deploymentOrder from the ASD>DeploymentItems will be used. Based on the deploymentOrder, the SO CNFM Helm Client does: From the registered K8S Clusters, choose a target K8S cluster name With the helm command with --kubeconfig or kube-contenxt option, set the target K8S cluster to work with. Invoke the helm install command towards the target K8S cluster, passing the release name, enhanced helm chart and custom values file. Create a unique release name with the helm chart name prefix Store the release name to the as_instance object/database e.g., helm install <release> <chart> --kubeconfig ~/.kubeconfigs/<cluster_name>.kubeconfig Post Condition: Helm Chart(s) under an ASD are deployed in the target K8S Cluster	SO-3895 - Getting issue details... STATUS	3.18
		~~Task:~~ ~~Per DeploymentItem, SO CNFM shall send (with cluster id, parameter, cloud artifacts) to the SO CNF Adapter for the connection to K8S plugin~~ ~~Support Helm Template / Dry-run, Helm Install, Helm Uninstall and Helm Upgrade~~ ~~SO CNF Adapter APIs are being studied.~~ Note: for the initial PoC, the SO CNF Adapter will not be used.	N/A
		SO CNFM Updates the AS CNF Instance to AAI SO CNFM shall update the AS CNF instance to AAI, by leveraging AAI APIs The Delete operation handle Termination implicitly, and delete the AS CNF instance from AAI. Post Condition: AAI database is updated/deleted for AS CNF instance (e.g., generic_vnf, vf-module).	SO-3902 - Getting issue details... STATUS	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 Provide required CNF instance input parameters, which are defined in the ASD LCM RESTful Protocols to the SO request Create(Create/Instantiate) AS asdId (modelVersionId) user params Delete(Terminate/Delete) AS Send AS LCM orchestration requests to SO Pre Condition: SO, SO CNFM and AAI and SDNC are ready and running Cloud-regions and tenants are defined in AAI Operator K8S Clusters are registered Post Condition: CNF Orchestration request is processed and CNF is deployed in the target K8S cluster.	SO-3842 - Getting issue details... STATUS	4

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.

SO Internal Architecture

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

Future NS Consideration

The following diagram depict the NS connection of ASDs.

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)

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

<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

<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

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.

Instantiation of ASD Service CSAR - Day 1

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

Option A: use Helm Command:

Option B: use of CNF Adapter (this is not part of initial PoC)

Note: use of CDS is TBD.

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.

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

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