View file | ||||
---|---|---|---|---|
|
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
Code Block | ||||
---|---|---|---|---|
| ||||
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 ... ... |
Projects Impacted
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 |
Projects that enables the "centralized representation and consistent identification of cloud regions in ONAP"
Project | PTL | Committed for R3 | M1 | M2 | MVP | JIRA | ||
---|---|---|---|---|---|---|---|---|
1 | SO | |||||||
2 | VID | Yes | ||||||
3 | SDNC | Yes | ||||||
4 | Integration | Yes | ||||||
5 | OOF | |||||||
6 | VFC | Yes | ||||||
7 | UUI | Yes | ||||||
8 | MultiCloud | Yes | ||||||
9 | DCAE | |||||||
10 | DMaaP | Ramprasad Koya |