Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

User StoryAffected ComponentDescriptionJIRAPriorityPoC 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
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-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
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-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
    • expect no code impact

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


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:

  • ASD and App onboarding packages are stored in the Catalog Registry
  • Helm Chart(s) are stored in the Helm Artifact Registry
  • Image(s) are stored in the Image Registry
  • Target K8S Cluster(s) are ready
  • Cloud-Region and Tenants are defined in AAI
  • AAI shall support CRUDQ of ASD-based CNF Resources

    • Leverage existing AAI APIs
    • Leverage AAI K8S Resource schema which was defined for CNFO
      • Take a look at the CNFO logic how to interface with AAI
    • Investigate any new AAI APIs for ASD-based CNF Resources (future consideration)

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
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-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


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
      • e.g., helm chart pull <artifactId>


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




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
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-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

...