Versions Compared

Version Old Version 4 New Version 5
Changes made by

A. Seaudi

A. Seaudi

Saved on

Key

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

...

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.

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.


Image Added

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

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

...