5GC Instantiation and Modify Config flow through CDS

Contributors:

Former user (Deleted) , Vamshi Namilikonda <VN00480215@TechMahindra.com>, Thamlur Raju (Unlicensed)

Introduction / Background:

As part of the 5G slicing use case, the core NSSMF shall be instantiating a 5G core service which typically would comprise of AMF, SMF and UPF CNFs.

In order to demonstrate this use case, a dummy AMF, SMF and UPF helm charts are created. The configurations applied to these CNFs during instantiation and later as part of day 2 configurations comprise of S-NSSAI and the configuration mechanism is assumed to be configmap type of k8s. 

This page provides all the details on how to design a typical 5G core NS in SDC, provides helm charts for dummy AMF, SMF, UPF and CBA packages for day 0, day 1 and day 2 configurations. These artifacts could form as a base template / seed artifacts using which interested people could build upon it and try onboarding specific vendor 5G core CNFs and design the configurations for the same. The CDS package has distinct workflows to handle day 0, day 1 and day 2 configurations.  

The Network service could be instantiated through EXT-API component or by invoking SO Macro flow. In the E2E slicing use case this would be invoked by core NSSMF. 

Using the Frankfurt release one could try NS instantiation invoking the SO APIs to validate the CNF instantiation and configurations.

Features:

• Core NS instantiation using the Macro flow through NBI Automation.
• Instantiation, Day0, Day1 and Day2 configuration with help of SO, SDNC, Multicloud (k8s-plugin) and CDS.
• There are two E2E workflows involved i.e Macro POST (Instantiation) and PUT (Modify Config) operations.

CBA package Download:

Original Upload

https://gerrit.onap.org/r/c/ccsdk/cds/+/113518 (obsolete)

https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=commit;h=a8fecedef955a594716d96a4c5b5c2564385db1c (obsolete)

Current Repository

https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/5GC_Simulator_CNF_CDS

Helm Package:

CCSDK-2919 - Getting issue details... STATUS

1. POST: Instantiation, Day0 and Day1 (will update the snssai value in CNF while creation/Instantiation) will perform.
2. PUT: Day2 can perform (will update the snssai value for Modify Config flow).

Description:

Realize the 5G Slicing CNF instantiation of dummy AMF, SMF and UPF network components as PODs in the k8s cluster and applying slicing configurations via ConfigMap k8s resource.

The following pre-requisites are required on ONAP Frankfurt instance to execute the usecase.

· Dummy Helm Charts to instantiate AMF, SMF & UPF

• CBA package
• NBI – NBI image 7.0.2
• SO – SO image 1.7.1
• Multicloud/K8splugin – Multicloud image latest

Helm artifacts for AMF, SMF & UPF:

1. Instantiation, day0 & day1
   1.  Base helm package amf_cloudtech_k8s_charts.tgz for instantiation contains following resources.

                 b. Profile artifact template-profile.tar.gz contains the following resources.

profile artifact carries snssai parameters for the day0 slice configurations inside override_values.yaml

Day2:

Config templates for each AMF, SMF & UPF instances as helm package for the day2 configurations contains the following resources. For instance the amf config template amf-config-template.tar.gz for AMF instance contains following resources

Config template helm package will be placed inside CBA package along the side profile artifact.

The day2 config-templates will be modified from the Kotlin script before uploaded to multicloud with the ConfigMap name already instantiated. This is to ensure that config-template would update the same ConfigMap which is existing already.

CBA package impacts:

The following new workflows introduced in the CBA along with the existing workflow “resource-assignment” compare to firewall CNF usecase from the Frankfurt.

1. Instantiation, Day0 & Day1
   • resource-assignment
               This CDS workflow executes kotlin script K8sProfileUpload.kt – responsible to upload profile artifact.
   • config-assign
   • config-deploy
               This CDS workflow executes kotlin script DayOneConfig.kt – responsible to update the config-template with appropriate(instantiated configmap) ConfigMap name and upload it using K8splugin config template API. This is being invoked
     from SO POST api.
2. Day2
   1. config-assign-day-2
   2. config-deploy-day-2

                     This CDS workflow executes kotlin script KotlinK8sUpdateConfig.kt – responsible to execute K8splugin Values API for day2 configurations. This is being invoked from SO PUT api.

Design time activities:

POST Operation Process:

In SDC vf Design --> create a property as "snssai" and declare it as input in Properties Assignment section, Even in service design refer that same VF and declare it as input.

SDC:

VSP:

VF:
Set below properties values at VF level in SDC

Service:

Instantiation Type = Macro

Set below properties values at Service level in SDC

• Set “skip_post_instantiation_configuration = false” in SDC to enable post
• controller_actor = CDS
• Add cba package details in sdnc properties
  • sdnc_artifact_name
  • sdnc_model_name
  • sdnc_model_version

NBI Updates:

WARNING:  The default override values file supplied with your distribution likely has this entry for nbi.

nbi:
  enabled: false
  config:
    # openstack configuration
    openStackRegion: "Yolo"
    openStackVNFTenantId: "1234"

This entry will cause changes you make to configure NBI to be overwritten when the NBI pod is updated and must be removed.

path: oom/kubernetes/nbi/templates/deployment.yaml 

The default values can remain as is as the values are specified in a values.yaml file.  Prior instructions added k8s config variables but that as of Istanbul is no longer needed.

            - name: ONAP_LCPCLOUDREGIONID
              value: {{ .Values.config.openStackRegion }}
            - name: ONAP_TENANTID
              value: {{ .Values.config.openStackVNFTenantId | quote }}
            - name: ONAP_CLOUDOWNER
              value: {{ .Values.config.cloudOwner }}
            - name: ONAP_K8SCLOUDREGIONID
              value: {{ .Values.config.k8sCloudRegionId }}
            - name: ONAP_K8SCLOUDOWNER
              value: {{ .Values.config.k8sCloudOwner }}

path: oom/kubernetes/nbi/values.yaml

The Values that come with the deployment are as below.

# application configuration
config:
  loglevel: INFO
  logstashServiceName: log-ls
  logstashPort: 5044
  cloudOwner: CloudOwner
  k8sCloudRegionId: k8sregionfour
  k8sCloudOwner: k8scloudowner4
  ecompInstanceId: OOM
  openStackRegion: RegionOne
  openStackVNFTenantId: aaaa

Two of these values (cloudOwner and openStackRegion need to be set to the k8s values;

# application configuration
config:
  loglevel: INFO
  logstashServiceName: log-ls
  logstashPort: 5044
  cloudOwner: k8scloudowner4
  k8sCloudRegionId: k8sregionfour
  k8sCloudOwner: k8scloudowner4
  ecompInstanceId: OOM
  openStackRegion: k8sregionfour
  openStackVNFTenantId: aaaa

Note: This will disable NBI being able to orchestrate in RegionOne on VM's and only deploy CNF's on default k8sregionfour. If you don't use your k8s info and keep openstack options, options, leaving the public_net_id null in your request will default to the openstack values, and if you give it something else, it will use k8s values.

To recap, update the values in the confg section of the NBI values..yaml.

• openStackRegion = the k8s region
• cloudOwner = value for k8s cloud owner
• openStackVNFTenantId = the same tenantid value for

SO Maria DB:

MariaDB [catalogdb]> select * from  orchestration_flow_reference;

| 429 | Service-Macro-Create | 1 | AssignServiceInstanceBB | 1 | 102 | NULL | NULL |
| 432 | Service-Macro-Create | 2 | CreateNetworkCollectionBB | 1 | 102 | NULL | NULL |
| 435 | Service-Macro-Create | 3 | AssignNetworkBB | 1 | 102 | NULL | NULL |
| 438 | Service-Macro-Create | 4 | AssignVnfBB | 1 | 102 | NULL | NULL |
| 441 | Service-Macro-Create | 5 | AssignVolumeGroupBB | 1 | 102 | NULL | NULL |
| 444 | Service-Macro-Create | 6 | AssignVfModuleBB | 1 | 102 | NULL | NULL |
| 447 | Service-Macro-Create | 7 | ControllerExecutionBB | 1 | 102 | vnf | config-assign |
| 450 | Service-Macro-Create | 8 | AssignPnfBB | 1 | 102 | NULL | NULL |
| 453 | Service-Macro-Create | 9 | WaitForPnfReadyBB | 1 | 102 | NULL | NULL |
| 456 | Service-Macro-Create | 10 | ActivatePnfBB | 1 | 102 | NULL | NULL |
| 459 | Service-Macro-Create | 11 | CreateNetworkBB | 1 | 102 | NULL | NULL |
| 462 | Service-Macro-Create | 12 | ActivateNetworkBB | 1 | 102 | NULL | NULL |
| 465 | Service-Macro-Create | 15 | CreateVolumeGroupBB | 1 | 102 | NULL | NULL |
| 468 | Service-Macro-Create | 16 | ActivateVolumeGroupBB | 1 | 102 | NULL | NULL |
| 471 | Service-Macro-Create | 17 | CreateVfModuleBB | 1 | 102 | NULL | NULL |
| 474 | Service-Macro-Create | 18 | ActivateVfModuleBB | 1 | 102 | NULL | NULL |
| 477 | Service-Macro-Create | 19 | ControllerExecutionBB | 1 | 102 | vnf | config-deploy |
| 480 | Service-Macro-Create | 20 | ActivateVnfBB | 1 | 102 | NULL | NULL |
| 483 | Service-Macro-Create | 21 | ActivateNetworkCollectionBB | 1 | 102 | NULL | NULL |
| 486 | Service-Macro-Create | 22 | ActivateServiceInstanceBB | 1 | 102 | NULL | NULL |

Check if cloud details are present in cloud_sites table. If does not exists then insert the same


insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregion", "k8sregion", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");

Instantiation of slice, day-0 configurations:

Process:

1. NBI receives 5G Slice order request to process. SO creates the service instance and updates service instance information to A&AI. SO further triggers SDNC to create service instance info in MD-SAL. SDNC further triggers CDS to execute resource assignment workflow.
2. SO creates VNF and updates VNF information to A&AI. SO further triggers SDNC to create VNF info in MD-SAL. SDNC further triggers CDS to execute resource assignment workflow.
3. SO creates vf-module and updates vf-module information to A&AI. SO further triggers SDNC to create VNF info in MD-SAL. SDNC further triggers CDS to execute resource-assignment workflow. The workflow triggers kotlin script KotlinK8sProfileUpload.kt which updates profile artifact with snssai parameters and create profile in K8splugin.
4. SO triggers config-assign workflow in CDS. CDS processes config-assign workflow.
5. SO invokes infra-workload API of Multicloud which further invokes K8splugin. Before processing of instantiating helm charts, the K8splugin retrieves profile artifact and updates the ConfigMap with snssai information from override.yaml of profile artifact.
6. SO updates A&AI with vf-module status as Activated.
7. SO triggers config-deploy workflow of CDS. CDS processes the config-deploy workflow. The workflow would execute kotlin script KotlinDayOneConfig.kt. The script performs the following activities in sequence. Steps from b) to f) will be executed for
   all the vf-modules except base.
   1. Script invokes A&AI and fetch vf-modules details
   2. From each vf-module response it retrieves heat-stack-id which is actually k8splugin instance id.
   3. With instance-id, invokes K8splugin /instance API to fetch ConfigMap name information.
   4. Updates the ConfigMap name in config-template artifact.
   5. Executes Create template API of K8splugin
   6. Uploads the config-template artifact by invoking Upload config template content API of K8splugin.
8. SO updates A&AI with VNF status as Active.
9. SO updates A&AI with Service Instance status as Active.

Notes:

• Updated slice information on the ConfigMap and inside pod supportedNsssai inside ConfigMap:

• Inside the AMF, SMF & UPF pods the slice details updated in the following location like below.

PUT Operation Process:

MariaDB [catalogdb]> select * from service_recipe;

insert into service_recipe (id,ACTION,VERSION_STR,DESCRIPTION,ORCHESTRATION_URI,SERVICE_PARAM_XSD,RECIPE_TIMEOUT,SERVICE_TIMEOUT_INTERIM, CREATION_TIMESTAMP,SERVICE_MODEL_UUID) Values(500,'updateInstance','1.0','Gr api recipe to update service-instance','/mso/async/services/WorkflowActionBB',NULL,180,NULL,'2020-09-01 16:08:35','d88da85c-d9e8-4f73-b837-3a72a431622b');

MariaDB [catalogdb]> select * from northbound_request_ref_lookup;

INSERT INTO northbound_request_ref_lookup(ID, REQUEST_SCOPE, MACRO_ACTION, ACTION, IS_ALACARTE, MIN_API_VERSION, MAX_API_VERSION, IS_TOPLEVELFLOW, CLOUD_OWNER, SERVICE_TYPE) VALUES (500, 'Vnf', 'VNF-Macro-Modify', 'updateInstance', 0, 7, 7, 1, 'k8scloudowner', '*');

MariaDB [catalogdb]> select * from orchestration_flow_reference;

insert into orchestration_flow_reference (id,COMPOSITE_ACTION,SEQ_NO,FLOW_NAME,FLOW_VERSION,NB_REQ_REF_LOOKUP_ID,SCOPE,ACTION)  values (901, 'VNF-Macro-Modify',1,'ControllerExecutionBB',1,500,'vnf','config-assign-day-2');
insert into orchestration_flow_reference (id,COMPOSITE_ACTION,SEQ_NO,FLOW_NAME,FLOW_VERSION,NB_REQ_REF_LOOKUP_ID,SCOPE,ACTION) values (902, 'VNF-Macro-Modify',2,'ControllerExecutionBB',1,500,'vnf','config-deploy-day-2');

Modify-Config flow of slice (Day-2):

Process: 

1. SO triggers PUT request for day2 configuration.
2. SO triggers config-assign-day-2 workflow of CDS. CDS executes the workflow.
3. SO triggers config-deploy-day-2 workflow of CDS. CDS processes config-deploy-day-2 workflow. The workflow would execute kotlin script KotlinK8sUpdateConfig.kt. The script performs the following activities in sequence. Steps from b) to c) will be executed for all the vf-modules except base.
   1. Script invokes A&AI and fetch vf-modules details
   2. Resolve snssai array
   3. Execute Config Values API of K8splugin by passing

Notes:
     Kotlin processing of snssai array from

SO PUT request SO PUT api would apply slice configurations on AMF, SMF and UPF instances. The PUT request carries the slice details which further been updated on the k8s cluster on the configmap.
The following json structure represents the configurations received from SO PUT for a VFModule.
The sNssai array would be resolved from the CBA to make it available to Kotlin

• Kotlin invocation of values api of K8splugin 
• The following configuration api from the multicloud/k8splugin would be invoked to process configurations. It takes configuration template as input in the payload which essentially contains helm package that carries configurations like
  ConfigMap in this case.

POST https://<IP>:30283/api/multicloud-k8s/v1/v1/rb/definition/<rbname>/<rb-version>/profile/<profile-name>/config

• Updated slice information on the ConfigMap and inside pod
       supportedNsssai inside ConfigMap:

Inside the AMF, SMF & UPF pods the slice details updated in the following location like below.