| Function | Affected Component | User Story & Description | JIRA |
|---|
| 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
| |
|
|
|
|
| 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
Post Condition: - SO API Handler receives SO requests and invoke BPMN Infra Workflow(s) for AS LCM.
| |
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 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 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
| |
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
 Image Added
 Image Added
| |
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
Post Condition: - SO CNFM Create AS is invoked and AsInstance object is returned if the operation is successful; otherwise, an error will be returned
| |
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
Post Condition: - SO CNFM Instantiate AS is invoked and the request is accepted
| |
Enhance Delete AS Workflow(s) to launch SO CNFM for Delete AS - SO BPMN Infra shall delegate ASD-based CNF orchestration to SO CNFM
Post Condition: - SO CNFM Delete AS is invoked and the AS instance and associated resource are deleted
| |
|
|
| 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: | |
Create ASD LCM REST API Swagger Post Condition: - Swagger file is ready for SO CNM NBI
| |
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:
- For multiple operator K8S Cluster support, the following operations are supported (stretch goal)
Post Condition: - SO CNFM NBI API Handler is ready to receive SO BPMN Infra requests, with no-ops
| |
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)
| |
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)
| |
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)
| |
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
| |
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
| |
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 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
Note: for initial PoC, Helm Charts are received from SDC (tbd) Post Condition: - SC CNFM collects all the associated Helm Charts.
| |
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.
| |
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.
|
(moved to London release) |
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 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
|
(moved to London release) |
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+) |
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) |
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) |
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 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 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.
| |
