Versions Compared

Version Old Version 7 New Version 8
Changes made by

A. Seaudi

A. Seaudi

Saved on

Key

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

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

View file
namevdns-cds-dublin-7-6-2019.mp4
height250

Summary of the video demo:

Before running the instantitation, we need to distribute the vDNS service model in ONAP.

...



  • 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.
Note
titleSTEP 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.

Code Block
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:

...

  • 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:

...