You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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:



  • 1st Rest call will give us the service model details like UUID, Invariant UUID, and Service Model Name.

  • 2nd Rest call will give us the VNF and VF Module details.

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
  • 3rd Rest call will pull the details from the 1st and 2nd calls, and build the SO Service Assignment and Activation request.
  • I added a 4th Rest call in the collection that will pull the request id from the 3rd call coming from SO, and will show us the status of the requets, so we can track the progress, and see if it completes successfully.

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.


SO Instantiation call and response


  • No labels