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

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

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

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

Projects that enables the "centralized representation and consistent identification of cloud regions in ONAP"