Page History

...

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)	1	Identifier that identifies the ASD which defines the AS instance to be created.
      asInstanceDescription	String	0..1	Human-readable description of the AS instance to be created.
      asInstanceName	String	0..1	Human-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..N	contains ext cpd parameter instance-level value
      deploymentItems	DeploymentItems	1..N	contains lifecycle parameters for deploymentItems
      additionalParams	KeyValuesPairs	0..1	Additional 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

        deploymentItemId	Identifier	1	Identifies which deploymentItem
        lifecycleParameterKeyValues	KeyValuesPairs	0..N	provides 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

...