Introduction
The purpose of this page is to describe the vDNS use case instantiation using the Controller Design Studio in ONAP Dublin Release.
Design Phase
In this section we desribe the design phase of the use case
Runtime Phase
In this section we describe the Runtime Phase which has the objective of instantiating the vDNS use case on OpenStack.
Video demo of the vDNS instantiation
Summary of the video demo:
Before running the instantitation, we need to distribute the vDNS service model in ONAP.
Then, we can use a Postman collection that has 3 Rest Calls and some code to automate the instantiation of the vDNS use case:
| |
STEP CDS2: Expose SO Catalog API SO Catalog DB is NOT exposed by default, you will need something like the command below to be able to send the CDS #2 rest call to SO Catalog and get back the service VNF model details. kubectl -n onap expose pod onap-so-so-catalog-db-adapter-56d9cc554b-9fszd --type=LoadBalancer | |
| |
|
Environment preparation for the Postman Collection:
In order to run the Postman collection correctly, we need to create 3 environment variables in Postman:
- cds-service-model: This is the name of the service model distributed by the robot script, you can find it by running CDS #1 call once and looking for the VNF that has today's date and time.
- cds-instance-name: This is the name of the service instance we will instantiate.
- k8s: This is our ONAP Load Balancer IP Address.
Also, we need to update our IaaS Openstack parameters in the body of the SO Service Instantiation Rest call CDS#3:
- lcpCloudRegionId : the cloud-region name
- tenantId : the tenant id
- public_net_id : the public network id in Openstack
- onap_private_net_id : the private network id in Openstack, we need this as this is not created by the auto assignment service
- onap_private_subnet_id : and the private subnet id
- pub_key : the public key to be put on the VMs
- image_name : Ubuntu 16 image name
- flavor_name : flavor
- sec_group : security group that will be applied to the VMs
SO Workflow BBs
After the Service Instantiation Rest Call to SO, we can see that SO decomposes the service into 1 VNF + 4 VF Modules, and 18 Building Blocks.
In the video below we can see the BBs as they progressing, until the full workflow is completed, and in the video shows the stack as it comes up in Openstack.
SO ConfigAssignBB
In this BB, a configlet is generated and saved in CDS DB.
The snapshot below shows the table, we can see we have 2 configs, one called baseconfig, and another called incremental config.
SO ConfigDeployBB
In this BB, the config generated by ConfigAssign from teh CDS DB, and push the config to the network element.
This happens via a python script that uses netconf library to connect to the vLB and deploys the baseconfig and the incremental config on the vLB via Netconf.
Results of the Postman Rest calls:
Below the output of the calls shown in the video: