Versions Compared

Key

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

...

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)

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySO-3808

1








User Story

for the required parameters
Instantiation time parameters such as network parameters and helm chart values overrides will be passed thru the above 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 to AAI
  • 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 3840
    User StoryFunctionAffected ComponentUser Story & DescriptionJIRAPriorityPoC 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
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    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 CNF model info and decide flows

    Pre Condition:

    trigger Create AS Instance workflow(s).

    • SO API shall be able to process AS LCM requests
    • Create/enhance BPMN Infra workflow(s) for AS orchestration
    • SO shall be able to map AS LCM requests to the predefined AS master workflow(s) in BPMN Infra
    • Create AS workflow(s) for Create AS
    • BPMN Infra workflow(s) shall launch the Create AS workflow(s)

    Pre Condition:

    • SO CNFM is running and ready to receive requests
    • SO CatalogDB contains ASD Model metadata
      • e.g., 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 

    Post Condition:

    • Create AS workflow(s) perform Create AS service task(s) that write log messages for recording task activities

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3840

    2

    For ASD-based CNF provisioning, SO shall process CNF model info and trigger Instantiate AS Instance workflows.

    • Create AS-CNF workflow(s) for Instantiate AS
    • Enhance BPMN Infra workflow(s) to add the Instantiate AS service task(s)
    • BPMN Infra workflow(s) shall launch the Instantiate AS workflow(s)

    Pre Condition:

    • Create AS Workflows have been performed

    Post Condition:

    • Instantiate AS workflow(s) perform Instantiate AS service task(s) that write log messages for recording task activities

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3881



    For ASD-based CNF provisioning, SO shall process CNF model info and trigger Delete AS Instance workflows.

    • Create AS-CNF workflow(s) for Delete AS
    • Enhance BPMN Infra workflow(s) to add the Delete AS service task(s)
    • BPMN Infra workflow(s) shall launch the Delete AS workflow(s)

    Pre Condition:

    • Create/Instantiate AS Workflows have been performed

    Post Condition:

    • Delete AS workflow(s) perform Delete AS service task(s) that write log messages for recording task activities

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3885



    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



    ONAP Admin Creates Cloud Region(s) and Tenant(s) 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

    Image Added

    Image Added

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3882

    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: SO endpoints could be enhanced for handling ASD-based CNF.

    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

    Image Added


    2.5

    Enhance 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

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-

    3883

    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

    Image Removed

    Image Removed

    2.1.6

    Enhance Instantiate AS Workflow(s) to launch SO CNFM for Instantiate AS 

    Post Condition:

    • SO CNFM Instantiate AS is invoked and the request is accepted

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3884



    Enhance Delete AS Workflow(s) to launch SO CNFM for Delete AS 

    Post Condition:

    • SO CNFM Delete AS is invoked and the AS instance and associated resource are deleted

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3886

    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: SO endpoints could be enhanced for handling ASD-based CNF.
    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

    Image Removed

    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
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    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

    Note: for the initial PoC, registration and deregistration could be out of scope (stretch goal)


    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

    Note: enhancedClusterCapbilities input parameter handling is a stretch goal. 


    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> 

    Note: for initial PoC, it is possible ASD is received from SDC (tbd)


    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>

    Note: for initial PoC, Helm Charts are received from SDC (tbd)


    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.13stretch goal (spike is needed)

    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.14Stretch goal

    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
    • The delete operation could update AAI, as termination.

    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
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-3842

    4

    Task: SO Client Invokes SO for AS LCM orchestration

    • 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

    Note: enhanced SO API could be used for ASD-based CNF.


    4.1

    ...