In the previous 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:
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" that subscribes to service "vFWCL":
curl -X PUT \ https://: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/",
"relationship-data": [
{
"relationship-key": "cloud-region.cloud-owner",
"relationship-value": "CloudOwner"
},
{
"relationship-key": "cloud-region.cloud-region-id",
"relationship-value": ""
},
{
"relationship-key": "tenant.tenant-id",
"relationship-value": ""
}
],
"related-to-property": [
{
"property-key": "tenant.tenant-name",
"property-value": ""
}
]
}’
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://:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/availability-zones/availability-zone/ \
-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": "",
"hypervisor-type": "",
"operational-status": "Active"
}'
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" as needed.
Example steps to add VIM/cloud instance info to SO:
# Procedure for mso_pass(encrypted)
# Go to the below directory on the kubernetes server
//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 bash
root@mso:/# vi /etc/mso/config.d/mso_config.json
"mso-po-adapter-config":
{
"identity_services":
[
{
"dcp_clli1x": "DEFAULT_KEYSTONE_Region1x",
"identity_url": ">/v2.0",
"mso_id": "",
"mso_pass": "",
"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": "",
"identity_service_id": "DEFAULT_KEYSTONE_Region1x"
},
# Save the changes and Restart MSO container
# Check the new config
http://: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=, 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=, adminTenant=service, memberRole=admin, tenantMetadata=true, identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD
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. This 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. Also if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP on Google Cloud in <1 hour), please contact us. Professional services include ONAP deployment, network service design/deployment, VNF onboarding, custom training etc.
References:
ONAP Wiki
vFWCL Wiki
