Biarca Blog

 

Questions? Ready to chat about how Biarca can help make your cloud vision a reality? LET’S TALK

Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP (Part 2 of 2)

In the last installment of this two part blog series, we looked at why NFV clouds are likely to be highly distributed and why the management and orchestration software stack needs to support these numerous clouds. ONAP is one such network automation software stack. We saw the first three steps of what it takes to register multiple OpenStack cloud regions in ONAP for the vFW use-case (other use cases might need slight tweaking).

Let’s pick up where we left off and look at the remaining steps, 4-7:

Step 4: Associate Cloud Region object(s) with a subscriber’s service subscription

With this association, this cloud region will be populated into the dropdown list of available regions for deploying VNF/VF-Modules from VID.

Example script to associate the cloud region “CloudOwner/Region1x” with subscriber “Demonstration2” which subscribe to service “vFWCL”:

curl -X PUT \  https://<AAI_VM1_IP>:8443/aai/v11/business/customers/customer/Demonstration2/service-subscriptions/service-subscription/vFWCL/relationship-list/relationship \
  -H 'accept: application/json' \
  -H 'authorization: Basic QUFJOkFBSQ==' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -H 'postman-token: 4e6e55b9-4d84-6429-67c4-8c96144d1c52' \
  -H 'real-time: true' \
  -H 'x-fromappid: jimmy-postman' \
  -H 'x-transactionid: 9999' \
 		 -d '	{
    "related-to": "tenant",
    "related-link": "/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/tenants/tenant/<Project ID>",
    "relationship-data": [
        {
            "relationship-key": "cloud-region.cloud-owner",
            "relationship-value": "CloudOwner"
        },
        {
            "relationship-key": "cloud-region.cloud-region-id",
            "relationship-value": "<Cloud Region - should match with physical infra>"
        },
        {
            "relationship-key": "tenant.tenant-id",
            "relationship-value": "<Project ID>"
        }
    ],
    "related-to-property": [
        {
            "property-key": "tenant.tenant-name",
            "property-value": "<OpenStack User Name>"
        }
    ]
}’

 

Step 5: Add Availability Zones to AAI

Now we need to add an availability zone to the region we created in step 3.

Example script to add OpenStack availability zone name, e.g ‘nova’ to Region1x:

curl -X PUT \
https://<AAI_VM1_IP>:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/availability-zones/availability-zone/<OpenStack ZoneName> \
-H 'accept: application/json' \
-H 'authorization: Basic QUFJOkFBSQ==' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-H 'postman-token: 4e6e55b9-4d84-6429-67c4-8c96144d1c52' \
-H 'real-time: true' \
-H 'x-fromappid: AAI' \
-H 'x-transactionid: 9999' \
-d '{
    "availability-zone-name": "<OpenStack ZoneName>",
    "hypervisor-type": "<Hypervisor>",
    "operational-status": "Active"
}'

 

Step 6: Register VIM/Cloud instance into SO

SO does not utilize the cloud region representation from A&AI. It stores information of the VIM/Cloud instances inside the container (in the case of OOM) as a configuration file. To add a VIM/Cloud instance to SO, log into the SO service container and then update the configuration file “/etc/mso/config.d/cloud_config.json” accordingly.

Example steps to add VIM/cloud instance info to SO:

# Procedure for mso_pass(encrypted) 
# Go to the below directory on the kubernetes server 

/<shared nfs folder>/onap/mso/mso
 
Then run: 
 
$ MSO_ENCRYPTION_KEY=$(cat encryption.key)
$ echo -n "your password in cleartext" | openssl aes-128-ecb -e -K $MSO_ENCRYPTION_KEY -nosalt | xxd -c 256 –p
 
# Need to take the output and put it against the mso_pass 
# value in the json file below. Template for adding a new cloud 
# site and the associate identity service
$ sudo docker exec -it <mso container id> bash
root@mso:/# vi /etc/mso/config.d/mso_config.json
 
"mso-po-adapter-config":
    {
      "identity_services":
      [
        {
          "dcp_clli1x": "DEFAULT_KEYSTONE_Region1x",
          "identity_url": "<keystone auth URL https://<IP or Name>>/v2.0",
          "mso_id": "<OpenStack User Name>",
          "mso_pass": "<created above>",
          "admin_tenant": "service",
          "member_role": "admin",
          "tenant_metadata": "true",
          "identity_server_type": "KEYSTONE",
          "identity_authentication_type": "USERNAME_PASSWORD"
        },
 	"cloud_sites":
      [
        {
          "id": "Region1x",
          "aic_version": "2.5",
          "lcp_clli": "Region1x",
          "region_id": "<OpenStack Region>",
          "identity_service_id": "DEFAULT_KEYSTONE_Region1x"
        },
 
# Save the changes and Restart MSO container
# Check the new config 
http://<mso-vm-ip>:8080/networks/rest/cloud/showConfig # Note output below should match parameters used in the CURL Commands

# Sample output:
 
Cloud Sites:
CloudSite: id=Region11, regionId=RegionOne, identityServiceId=DEFAULT_KEYSTONE_Region11, aic_version=2.5, clli=Region11
CloudSite: id=Region12, regionId=RegionOne, identityServiceId=DEFAULT_KEYSTONE_Region12, aic_version=2.5, clli=Region12

Cloud Identity Services:
Cloud Identity Service: id=DEFAULT_KEYSTONE_Region11, identityUrl=<URLv2.0, msoId=<OpenStackUserName1>, adminTenant=service, memberRole=admin, tenantMetadata=true, identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD
Cloud Identity Service: id=DEFAULT_KEYSTONE_Regopm12, identityUrl=https://auth.vexxhost.net/v2.0, msoId=<OpenStackUserName2>, adminTenant=service, memberRole=admin, tenantMetadata=true, identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD

 

Step 7: Change Robot service to operate with the VIM/Cloud instance

When using OOM, by default the Robot service supports the pre-populated cloud region where the cloud-owner is “CloudOwner” and cloud-region-id is specified via the parameters “openstack_region” during the deployment of the ONAP instance through OOM configuration files. All cloud region information can be updated in the file “/share/config/vm_properties.py” inside the robot container. Appropriate relationships between Cloud Regions and Services need to be setup in the same file for Robot Service Tests to pass.

Note: Robot framework does not rely on Multi-VIM/ESR.

If you have done all 7 steps correctly, Robot tests should pass and both regions should appear in the VID GUI.

If you liked (or disliked) this blog, we’d love to hear from you. Please let us know. In the meantime if you are looking for Cloud Services — ONAP, OpenStack, Kubernetes, Cloud Native Application, DevSecOps and Infrastructure Modernization — please  contact us.

References:

ONAP Wiki
vFWCL Wiki

Contributor: Subba Rao Kodavalla

Leave a Reply

Your email address will not be published. Required fields are marked *