Overview

This is the page to track the realization of functional requirement of "Centralized Representation and Consistent Identification of Cloud Regions In ONAP" to facilitate the orchestration over multiple cloud regions .

The motivation of this functional requirement lies in the fact: with ONAP Amsterdam and Beijing Releases, there are 3 representation of a single cloud region in ONAP, and different ONAP components use different identification to refer to the same cloud region. This complicates the on-boarding process of a cloud region, also imposes unnecessary constraints of the choice of cloud regions,e.g. If there is 2 cloud region with the same cloud region id, only one of them can be on-boarded into ONAP.

The functional requirement is to centralize the representation of the cloud regions into AAI only by depreciating all other representations. All ONAP components should use the composite key of "{cloud-owner}, {cloud-region-id}" to refer to a cloud region.

By enforcing this functional requirement, ONAP users will be able to onboard a cloud region by either issuing a single curl command to AAI service, or a single click over ESR VIM registration GUI portal. The consistent ID of a cloud region will make it is easy to correlate the operations on a cloud region across the all ONAP services.

More Info about how AAI represent cloud regions in Beijing Release:

AAI REST API Documentation - Beijing

https://gerrit.onap.org/r/gitweb?p=aai/aai-common.git;a=blob;f=aai-schema/src/main/resources/aai_swagger_html/aai_swagger_v13.html;h=4100f41e007349b4c08517690da97a5b44e8865b;hb=HEAD

cloud-region Object from AAI schema v13

cloud-region: object  
	cloud-region designates an installation of a cloud cluster or region or instantiation
	...
	...
	cloud-owner: string  
		Identifies the vendor and cloud name. First part of composite key should be formatted as vendor-cloudname

	cloud-region-id: string  
		Identifier used by the vendor for the region. Second part of composite key
	...
	...

Action Plan A: Make it ready within a single Release

Projects Impacted

project	proposed changes

project	proposed changes
SO	1, Depreciate the usage of internal representation of cloud region. Use centralized representation of cloud region in AAI instead. 2, Depreciate the usage of "cloud-region-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
VID	Depreciate the usage of "cloud-region-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
SDNC	Depreciate the usage of "cloud-region-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
OOF	Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
VFC	Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
MultiCloud	Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
UUI	Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
Integration	1, Robot VM should depreciate the usage of internal representation of cloud region. Use centralized representation of cloud region in AAI instead. 2, Robot VM should allow users to specify the composite key of "{cloud-owner}, {cloud-region-id}" to execute scripts
DCAE	make sure dcaeLocation is derived from a cloud region + tenant, and can be translate to {cloud-owner } + {cloud-region-id} + {tenant} for retrieving cloud region information from AAI
DMaaP	make sure dcaeLocation is derived from a cloud region + tenant, and can be translate to {cloud-owner } + {cloud-region-id} + {tenant} for retrieving cloud region information from AAI

Plan B: Break into 3 phases and realized across multiple Releases:

Phase 1: Centralize the representation of cloud regions

- The centralization representation of cloud regions facilitate the on-boarding process of new VIM/Cloud instances.

- Nevertheless with constraints with regarding to the Identification of a cloud region

• value of “cloud-owner”: underscore character “_” cannot be used

• “cloud-region-id” should be unique across all cloud regions.

Projects Impacted

project	proposed changes

project

proposed changes

SO

Remove hard coded cloud sites, integrate with MultiCloud for heat based VNF orchestration.

Integration

1, Refactor robot scripts: depreciate the usage of local configuration file: vm_properties.py; allow scripts users to specify the “cloud-owner” and “cloud-region-id”

2,

Refactor robot scripts: populate the default cloud region into AAI with correct information: align to ESR VIM registration.

Phase 2: Consistent ID of a cloud region

All ONAP projects agree on the usage of consistent ID to specify a cloud region

• Composed keys {cloud-owner} , {cloud-region-id} is preferred choice

Projects Impacted

project	proposed changes

project

proposed changes

MultiCloud

Upgrade the API version, use composed keys {cloud-owner} + {cloud-regionid}

instead of {vim-id} to specify a cloud region

VID/SO/SDNC/OOF

Use composed keys {cloud-owner} + {cloud-region-id} instead of just {cloud-region-id} to specify a cloud region.

VFC,UUI

Use composed keys {cloud-owner} + {cloud-region-id} instead of {vim-id} to specify a cloud region

Phase 3: Correlate and align dcaeLocation to AAI’s cloud region

To be researched/clarified:

1,AAI's cloud region is the representation of VIM/Cloud instance for VNF orchestration

2, It seems dcaeLocation is the representation of VIM/Cloud instance for ONAP components distributed deployment

3,It is not clear yet if dcaeLocation should be correlated/aligned to AAI's cloud region.

In case dcaeLocation should be correlated/aligned to AAI's cloud region:

- dcaeLocation is equivalent to AAI’s cloud region + tenant.

- DMaaP may have their own cache/storage of the daceLocation

- Make sure the daceLocation is derived from AAI’s cloud region

• Cloud Region is on-boarded into AAI once, no need to create dcaeLocation

• CLAMP user retrieves the Cloud Region information from AAI and create dcaeLocation accordingly

Projects Impacted

project	proposed changes

project	proposed changes
CLAMP	Retrieve cloud region from AAI, then distribute the cloud region’s information to DCAE/DMaaP to create dcaeLocation
DCAE/DMaaP	Some synchronization mechanism should be applied to ensure the updated cloud region information will be synced to dcaeLocation