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

1








User Story

FunctionAffected 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

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.

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

1Task: SO SDC

  • 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
.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.2For ASD-

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






For ASD-based CNF provisioning, SO shall process model info
and
, decide flows and invoke SO CNFM for AS LCM

API Handler,

RequestDB Adapter,

RequestDB,

SO BPMN Infra, 

AAI

SO CNFM

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

Enhance SO API Handler and BPMN Infra workflow(s)

.

for AS LCM

  • SO
API
  • endpoints 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 CatalogDB contains ASD Model metadata
      • e.g., Resource VF TOSCA.metadata "ASD" entry_definition_type

    Post Condition:

    Create AS workflow(s) perform Create AS service task(s) that write log messages for recording task activities
    • 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.

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-

    3840Create AS-CNF

    3905

    2

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


    SO BPMN Infra shall trigger Create AS Instance workflow(s)

    for Instantiate AS

    .

    • Enhance BPMN Infra workflow(s) to add
    the Instantiate AS service task
    • the Create AS workflow(s) for Create AS
    • BPMN Infra workflow(s) shall launch the
    Instantiate Create AS Workflows have been performed
    • Create AS workflow(s)

    Pre Condition:

    • Create AS workflow(s) invokes SO CNFM thru AS LCM Restful Create AS APIs

    Post Condition:

    Instantiate AS workflow(s) perform Instantiate AS service task(s) that write log messages for recording task activities
    • SO CNFM Create AS NBI is invoked for Create AS

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-

    3881

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

    Create AS-CNF

    3840

    2.1

    SO BPMN Infra shall trigger Instantiate AS Instance workflow(s)

    for Delete AS

    .

    Enhance
    • BPMN Infra main workflow(s)
    to add
    • shall launch the
    Delete AS service task(
    • enhanced AS workflow(s) for Instantiate AS
    • Enhance BPMN Infra AS workflow(s)
    shall launch the Delete 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
    /Instantiate
    • AS Workflows have been performed

    Post Condition:

    Delete
    • Instantiate AS
    workflow
    • service task(s)
    perform Delete AS service task(s) that write log messages for recording task activities
    • invoke Instantiate AS operations and get acknowledgment/error and get the Instantiate AS status

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

    Image Removed

    3881

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3885

    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

    Image Added

    Image Added

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3882

    2.4

    In BPMN Infra, create the Create AS Workflow(s) to launch SO CNFM for Create AS 

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

    2.5

    Enhance Instantiate AS Business Logic (Java code) to launch SO CNFM for Instantiate AS 

    Post Condition:

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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3884

    2.6

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

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057

    -3a0f-ae5e-4fd8aff50176keySO-38822.1Task: 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

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

    Post Condition:

    SO CNFM Create AS is invoked and AsInstance object is returned if the operation is successful; otherwise, an error will be returned

    -3a0f-ae5e-4fd8aff50176
    keySO-3888

    3

    Create ASD LCM REST API Swagger

    Post Condition:

    • Swagger file is ready for SO CNM NBI

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3889

    3.1

    Create SO CNFM NBI API Handler based on ASD LCM Restful Protocol swagger, no-ops

    Post Condition:

    • SO CNFM NBI API Handler is ready to receive SO BPMN Infra requests, with no-ops

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3890

    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)

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-

    3883

    3893

    2
    3.
    6

    Enhance Instantiate AS Workflow(s) 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 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 InstantiateAsRequest, get:
      • asdExtCpdInputParams
      • deploymentItems
      • additionalparams
  • As a SO CNFM client, use the following client operations to  invoke  SO  CNFMASD LCM RESTful Protocols for SO CNF Manager
    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)

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3904

    3.4

    Implement Delete AS Business Logic in SO CNFM NBI Handler to invoke Delete AS workflows(s)

    Post Condition:

    • SO CNFM
    Instantiate AS is invoked and the request is accepted
    • NBI Handler is able to invoke Delete AS workflow(s)

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

    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

    keySO-3894

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO

    -3886

    Task: SO BPMN Infra Invocation for SO CNFM for AS LCM

    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 

    -3891

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3906

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3892

    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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3897

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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-

    3841

    3898

    3.10
    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

    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.

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3899

    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.

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3900

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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3901

    (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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3896

    (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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3895

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

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-3902

    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.

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

    keySO-38424

    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

    keySO-3842

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

    ...

    Gliffy
    macroIdaeb90e14-5c2e-46f5-b852-941a6f60f21a
    displayNameSO ASD CNF Orchestration
    nameSO ASD Orchestration
    pagePin40


    Future NS Consideration

    The following diagram depict the NS connection of ASDs.




    Image Added

    Gliffy
    macroId2484887f-ebeb-4d63-a31b-ada9c0bf36c7



    AS LCM Restful API

    Please refer to the section, ASD AS LCM RESTful Protocols for SO CNF Manager .


    Gliffy
    macroId35667bf9-261a-4ae2-b40c-d8e94ab2b643
    displayNameSO BPMN Infra - SO CNFM NBI Rest APIs
    nameSO BPMN Infra - SO CNFM NBI Rest APIs
    pagePin3

    ...

    • <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..Ncontains ext cpd parameter instance-level value

          deploymentItems

          DeploymentItems1..Ncontains lifecycle parameters for deploymentItems
          additionalParamsKeyValuesPairs0..1Additional 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

            deploymentItemIdIdentifier1Identifies which deploymentItem

            lifecycleParameterKeyValues

            KeyValuesPairs0..Nprovides 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)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 helm client will be used
            • 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

    ...

    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.

    ...

    • 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

    ...