User Story | Affected Component | 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 | 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
| Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SO-3839 |
---|
|
| 1 |
|
Task: SO SDC Controller handles ASD-based CNF Service CSAR - 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.1 |
|
Task: 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.
|
| 1.2 |
|
For ASD-based CNF provisioning, SO shall process model info and decide flows | API Handler, RequestDB Adapter, RequestDB, SO BPMN Infra, AAI SO CNFM | For ASD-based CNF provisioning, SO shall process model info and decide flows Pre Condition: - SO CNFM is running and ready to receive requests
- SO CatalogDB contains ASD Model metadata
- Resource VF TOSCA.metadata "ASD" entry_definition_type
- SO Client provides parameters based on the ASD lifecycleParameter list
- Existing SO requests will be used to invoke SO
- The SO Request should include the parameters required for the ASD LCM Restful Protocols. See ASD LCM RESTful Protocols for SO CNF Manager for the required parameters
- Instantiation time parameters such as network parameters and helm chart values overrides will be passed thru the above ASD LCM RESTful Protocols to invoke SO CNFM
- note: use of CDA and CDS is a future consideration - out of scope
- The selection of the cloud-region (which represents K8S cluster) comes from the SO Service creation request
Post Condition: - SO CNF Manager (SO CNFM) receives requests from the SO BPMN Infra and gets ready to process the requests
- After the CNF Manager process, SO shall update CNF to AAI
| Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SO-3840 |
---|
|
| 2 |
|
Task: Cloud Region(s) and Tenant(s) Creation in AAI - 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
|
| 2.1 |
|
Task: Create & Configures ASD-based CNF workflows- Create new BPMN workflows for ASD-based CNF workflows
- Design to invoke SO CNF Manager
- Configure SO MacroFlows configurations for invoking ASD-based CNF workflows
|
| 2.2 |
|
Task: SO API Handler Enhancement - SO API Handler receives a service (or a la carte: make a design decision) request for ASD-based CNF and stores the request information into the Request DB
- Note: expect no change or minimum changes
|
| 2.3 |
|
Task: SO Create Service Instance to AAI - SO shall create service instance to AAI, leveraging existing AAI schema service
|
| 2.4 |
|
Task: SO BPMN Infra processes for ASD-based VF - 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
|
| 2.5 |
|
Task: SO BPMN Infra Invocation for SO CNFM for AS LCM - 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 (ASD LCM RESTful Protocols for SO CNF Manager ) and its swagger file (ASD LCM RESTful Protocols for SO CNF Manager)
- for CreateASRequest, get:
- asdId
- asInstanceName
- asInstanceDescription
- for InstantiateAsRequest, get:
- asdExtCpdInputParams
- deploymentItems
- additionalparams
- for TerminateAsRequest, get:
- terminationType
- gracefulTerminationTimeout
- addiontalParams
- for Delete AS, get:
- asInstanceId as a parameter
- As a SO CNFM client, use the following client operations to invoke SO CNFM
|
| 2.6 |
|
SO CNFM shall process ASD-based CNF Lifecycle orchestration
| SO CNFM, ASD Repository, Helm Artifact Repository, OOF, AAI, SDNC Adapter, SDNC
| SO CNFM shall process ASD-based CNF Lifecycle orchestration Pre Condition: Post Condition: - ASD-based CNF is provisioned by SO CNFM
Note: in the initial PoC, ASD external CPDs parameters for the primary network will be used (e.g., loadbalancerIP, externalIPs) to configure the K8s service or ingress controller that the ExtCpd represents Note: ASD Registry, Helm Artifact Registry, Image Artifact Registry will be handled by another Epic, which is defined in Application Package Distribution | Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SO-3841 |
---|
|
| 3 |
|
Task: 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
|
| 3.1 |
|
Task: Create ASD LCM REST API Swagger |
| 3.2 |
|
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 (ASD LCM RESTful Protocols for SO CNF Manager)
- Support the following service operations:
- For multiple operator K8S Cluster support, the following operations are supported:
|
| 3.3 |
|
Task: SO CNFM Input Parameter Handling - 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 used
|
| 3.4 |
|
Task: SO CNFM Accesses ASD Registry for Getting ASD - 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
- e.g., GET /api/asds/<name>
|
| 3.5 |
|
Task: SO CNFM Processes ASD - 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
|
| 3.6 |
|
Task: Create SO CNFM Instance Database Management - Create SO CNFM Database tables (not necessarily, RDBMS: make a design design) to store:
- incoming requests
- custom values.yaml files
- Provides Database Access Objects (DAO) for CRUD for SO CNFM
|
| 3.7 |
|
Task: SO CNFM Processes Instance-Level Helm Charts - SO CNFM shall support the capability to construct custom values file(s), by:
- applying Instance-level input parameter parameter values which came thru Task #3.4
- enhancing helm charts with resolved input parameter values which came thru Task #3.4
- generating new custom values file(s), based on the DeploymentItem parameter values which came thru Task #3.4
- SO CNFM shall store the generated helm charts and/or values files to the SO CNFM database
|
| 3.9 |
|
Task: 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
|
| 3.10 |
|
Task: SO CNFM Gets an AS Placement Information for a Target K8S Cluster - 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.11 |
|
Task: SO CNFM Makes a 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 make a placement decision based on the decision from the Placement component.
- In the initial PoC, a pre-selected K8S cluster (selected by the client) will be used.
- In the future, ASD enhancedClusterCapabilities attribute will be used to choose a proper/capable K8S cluster. Use of OOF is also a future consideration.
|
| 3.12 |
|
Task: 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
|
| 3.13 |
|
Task: 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.
|
| 3.14 |
|
Task: 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.
|
| 3.15 |
|
Task: 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 enhanced helm chart and custom values file.
|
| 3.16 |
|
Task:
Per DeploymentItem, SO CNFM shall send (with cluster id, parameter, cloud artifacts) to the SO CNF Adapter for the connection to K8S pluginSupport 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. |
|
|
|
Task: SO CNFM Updates the AS CNF Instance to AAI - SO CNFM shall update the AS CNF instance to AAI, by leveraging AAI APIs
|
| 3.17 |
|
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: - 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.
| Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SO-3842 |
---|
|
| 4 |
|
Task: SO Client Invokes SO for AS LCM orchestartion - Provide required CNF instance input parameters, which are defined in the ASD LCM RESTful Protocols to the SO request
- Send AS LCM orchestration requests to SO
|
| 4.1 |
|