Versions Compared

Old Version 122

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version 123

changes.mady.by.user Byung-Woo Jun

Saved on

Key

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

Table of Contents

...

User StoryAffected ComponentDescriptionJIRAPriority
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: 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
  • Task: 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
For ASD-based CNF provisioning, SO shall process model info and decide flows

API Handler,

RequestDB Adapter,

RequestDB,

SO BPMN Infra, 

AAI

SO shall process ASD model info and decide ASD provisioning flows

Pre Condition:

Post Condition:

  • CNF Manager receives requests from SO BPMN Infra and processes 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: 
  • Create & Configures ASD-based CNF workflows
    • Create new BPMN workflows for ASD-based CNF workflows
      • Design to invoke SO CNF Manager
    • Configure SO MacroFlows for ASD-based CNF workflows

2.1

Task:

  • SO API Handler receives a service (or a la carte) request for ASD-based CNF and stores the request information into the Request DB
    • Note: expect no change

2.2

Task: 

  • SO BPMN Infra decomposes Service into VF Resource(s) and per VF resource, SO BPMN process resource handling
    • If the VF resource metadata indicates the ASD-based VF, SO shall process ASD-based CNF workflows

2.3

Task:

  • SO shall create service instance to AAI
    • note: leverage AAI schema service; no code impact

2.4

Task:

  • SO shall delegate ASD-based CNF orchestration to SO CNFM
    • Pass input parameters including ASD reference Id, LifecycleParameter, etc.
    • note: until SO CNFM is ready, use no-opt operations as a place holder

2.5
SO CNFM shall process ASD-based CNF Lifecycle orchestration





















SO CNFM,

ASD Repository,

Helm Artifact Repository,

OOF,

AAI, 

SDNC Adapter,

SDNC,

CDS,

CNF Adapter


































SO CNFM shall process ASD-based CNF Lifecycle orchestration

Pre Condition:

  • ASD and App onboarding package is stored in the Catalog Repository
  • Helm Chart(s) are stored in the Helm Artifact Repository

  • AAI shall support CRUDQ of ASD-based CNF Resources

    • Leverage existing AAI APIs
    • Investigate any new AAI APIs for ASD-based CNF Resources (TBD)

Post Condition:

  • ASD-based CNF is provisioned by SO CNFM

Note: PoC, ASD external CPDs will not be handled (TBD)

Note: ASD Repository, Helm Artifact Repository, Image Artifact Repository 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
  • Make SO CNFM POD is deployable in OOM
  • Register SO CNFM POD to AAI automatically

3.1
Create SO CNFM REST API swagger, based on the ASD LCM Restful API, ASD LCM RESTful Protocols for SO CNF Manager and Swagger file (ASD LCM RESTful Protocols for SO CNF Manager)
3.2

Task: Support for SO CNFM NBI API Handler

  • SO CNFM shall support its NBI REST Apis to handle requests from SO.

3.3

Task:

  • SO CNFM shall support the capability to process input parameters from SO, and use the deployment parameters from ASD for the CNF deployment. Those deployment parameter values shall correspond to the parameters defined in the "lifecycleParameters" section(s) of the ASD.

3.4

Task:

  • SO CNFM shall communicate with the ASD Repository to get ASD (descriptor) and artifacts from the ASD repository Manager.

3.5

Task:

  • SO CNFM shall decompose ASD and get the associated DeploymentItems list
    • Get HelmChart references from the DeploymentItems
    • Get ASD from the Repository
      • GET /api/asds/<name> (TBD)

3.6

Task:

  • By leveraging the obtained HelmChart references, SO CNFM shall get associated Helm Charts from the Helm Repository Manager.
    • GET /api/charts/<name>/<version> 

3.7

Task: Create SO CNFM Instance Database Management

  • Create SO CNFM Database tables
  • Provides Database Access Objects (DAO) for CRUD for SO CNFM

3.8

Task:

  • SO CNFM shall support the capability to construct a values file from instance specific parameter values from SO and merge the values with default values from ASD Helm Chart values.
  • SO CNFM shall store the generated values file  for an instance to SO CNFM database

3.9

Task:

  • SO CNFM shall transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)

3.10

Task:

  • 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 shall make a placement decision based on the decision from the Placement component.

3.12

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. 

3.13

Task:

  • SO CNFM shall update the CNF instance to AAI, by leveraging AAI APIs

3.14

SO Client shall send the A La Carte Request for ASD-based CNF orchestration

(note: E2E support is out of PoC scope)

SO Client,

SO,

SO BPMN,

CNFM

CNF Adapter

SO Client shall send the A La Carte Request for ASD-based CNF orchestration

Pre Condition: 

  • SO, CNFM and CNFM Adapter are ready and running
  • AAI and SDNC are ready and running

Post Condition:

  • CNF Orchestration request is processed and CNF is deployed in K8S

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

4

Task:

  • Provide CNF instance input parameters, based on the lifecycleParameters from the ASD DeploymentItem
  • Provide asdExtCpd inputParamMappings for CNF deployment 
    • it is out of PoC scope

4.1

Task:

  • Use of CDS for instance parameter assignment is out of PoC scope (TBD)

4.2?

...

Gliffy
macroId1d151ab6-c47b-4e49-977b-21a22df33f45
displayNameASD LCM Orchestration-Jakarta
nameASD LCM Orchestration-Jakarta
pagePin89


SO Internal Architecture

The following diagram depicts SO internal architecture for the ASD-based orchestration:

...

  • <Create an AS Identifier>
    • SO CNFM receives the create request (CreateAsRequest) and processes the request and return a response with AsInstance

      • CreateAsRequest:

        asdId

        		Identifier (UUID)1Identifier that identifies the ASD which defines the AS instance to be created.

        asInstanceDescription

        		String0..1Human-readable description of the AS instance to be created.

        asInstanceName

        		String0..1Human-readable name of the AS instance to be created.


      • The client passes "asdId" to SO CNFM, so CNFM can query an ASD with the asdId from the ASD Repository

      • SO CNFM copies the incoming CreateAsRequest attributes into an AsInstance structure, and persists the AsInstance, which has a connection between the asInstanceId and asdId
      • note: SO CNFM will uses the asdId when it queries an ASD from the ASD Repository during the instantiation operation


    • When the Create AS instance is successful, SO CNFM returns 200 OK with the AsInstance
      • The returned AsInstance contains the asInstanceId
      • Subsequent operations uses the asInstanceId; i.e., the Client use the asIstanceId in the REST Api path

...

  • <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)
        • in the initial PoC, the helm client will be used
      • If successful, SO CNFM update the corresponding vf-module in the AAI

...

The cluster configuration file for a particular cluster must be retrieved from the cluster administrator.

The Cluster configuration file pre-requisities are:

  • It must start with an alphanumberic character
  • It can only contain alpahnumberic 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.

...

  • Update existing resources schema (Cloud-Region, Generic-VNF) and/or create CNF counterparts (VF-Module)
  • Store Resources definitions about Controllers (eg. Deployments), Compute (Pods, Containers), Storage (PV/PVC), Network (Pod Interfaces, Services) and Configuration resources (eg. ConfigMaps, Secrets).
  • Store unclassified resources like CRDs under “Uncategorized” - like object

Use of AAI Model K8S Resource Object

We are considering reuse of AAI K8S Resource Object, which was designed for CNFO.

Image Added

Use of AAI Model K8S Resource Object Relations

We are considering reuse of AAI K8S Resource Object Relations (TBD)

Image Added


SO ASDC Controller Handling

...