summaryrefslogtreecommitdiffstats
path: root/docs/specs/multicloud-multi-region.rst
diff options
context:
space:
mode:
authorBin Yang <bin.yang@windriver.com>2018-07-18 10:15:27 +0000
committerBin Yang <bin.yang@windriver.com>2018-08-14 12:05:30 +0000
commit9e3eaba3ce475451e3ad4e13c7c6d5c0512e1a14 (patch)
tree301834e5ca938cb4bd2838852d032d8efa124476 /docs/specs/multicloud-multi-region.rst
parent6e5bf56c01bc5dfac88b441d37e99fef1906150f (diff)
Propose automating multi-region on-boarding
This proposal describe how multicloud plugin helps automating of on-boarding the OpenStack secondary regions Change-Id: Icba078a6ff1462901e7e5240507925ac6f76edb9 Issue-ID: MULTICLOUD-279 Signed-off-by: Bin Yang <bin.yang@windriver.com>
Diffstat (limited to 'docs/specs/multicloud-multi-region.rst')
-rw-r--r--docs/specs/multicloud-multi-region.rst77
1 files changed, 77 insertions, 0 deletions
diff --git a/docs/specs/multicloud-multi-region.rst b/docs/specs/multicloud-multi-region.rst
new file mode 100644
index 0000000..b67626f
--- /dev/null
+++ b/docs/specs/multicloud-multi-region.rst
@@ -0,0 +1,77 @@
+..
+ This work is licensed under a Creative Commons Attribution 4.0
+ International License.
+ Copyright (c) 2017-2018 Wind River Systems, Inc.
+
+===============================
+MultiCloud Multi-Region support
+===============================
+
+This proposal describes how MultiCloud plugin automates the on-boarding of tens or hundreds of cloud regions by leveraging multi-region feature
+
+Problems Statement
+==================
+
+The ONAP functional requirement for Edge Automation aims to automate the VNF orchestration across edge stacks.
+
+..
+https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP
+
+Before VNF can be orchestrated over these edge stacks, these edge stacks must be on-boarded into ONAP. This can be a very big challenge in case of tens of or hundred of edge stacks. Fortunately, With OpenStack multi-region feature, the OpenStack primary region will expose
+all secondary regions' endpoints. Hence MultiCloud plugins could automate the discovery and registry
+of all OpenStack secondary regions.
+
+
+Proposed Design and Workflow
+============================
+
+**This automation assumes**:
+ - ONAP could use the same set of credentials (project, user/password) to access all OpenStack regions for orchestration.
+ - ONAP user will explicitly enable the automation of discovery OpenStack secondary regions during manually on-boarding the OpenStack primary region.
+ - ONAP users could manually manage the cloud regions representing those secondary regions just like a normal cloud region
+
+
+**With OpenStack primary region, the ONAP user will**:
+..
+https://wiki.onap.org/pages/viewpage.action?pageId=25431491
+ - Manually on-board this primary region with ESR VIM registration portal.
+ - Input the {cloud-owner} and {cloud-region-id} as the ID of cloud region which is unique.
+ - Specify the location id
+ - Specify the intention of automation of OpenStack secondary regions managed by this primary region. This intention is specified with key-value pair {"multi-region-discovery":"true"} populated to cloud region's property "cloud-extra-info"
+
+
+**With OpenStack primary region, the corresponding MultiCloud plugin will**:
+ - Discover all OpenStack secondary regions in case being explicitly indicated with key-value pair {"multi-region-discovery":"true"}
+ - Register each of discovered OpenStack regions as a new cloud region into AAI.
+ - Duplicate the credentials and location relationship from primary region.
+ - Duplicate all or part of the cloud region's property "cloud-extra-info",
+ - Add one more key-value pair to cloud region's property "cloud-extra-info": {"primary-region":["{cloud-owner}","{cloud-region-id}"]}
+ - Add relationship to the cloud region of primary region: to be checked.
+ - Generate the ID of cloud region representing the OpenStack secondary region with following rules:
+ - {cloud-owner} should be {cloud-owner of primary region}.
+ - {cloud-region-id} will be the concatenated string with format: {cloud-region-id of primary region}.{OpenStack Region ID}.
+ - The composite keys {cloud-owner},{cloud-region-id of primary region}.{OpenStack Region ID} will be unique since the composite key of primary region: {cloud-owner},{cloud-region-id} is unique.
+
+
+**With generated cloud region representing the OpenStack secondary region, the ONAP user could**:
+ - update the credentials so that the ONAP could use updated credentials to orchestrate VNF to this cloud region
+ - update the location of the cloud region by associating it to different complex object other than the one same to primary region.
+ - Update cloud region's property "cloud-extra-info".
+ - Decommission or delete the cloud region
+
+
+Appendix:
+=========
+
+There is a property of cloud region object named "cloud-extra-info"
+..
+https://wiki.onap.org/display/DW/AAI+REST+API+Documentation+-+Beijing
+
+::
+
+ cloud-extra-info: string
+ ESR inputs extra information about the VIM or Cloud which will be decoded by MultiVIM.
+
+the intention of this property is to enable the extending of cloud region object without impact AAI's schema. How and when to use this property is up to each multicloud
+plugin respectively. This property can be populated by ONAP users through ESR VIM registration GUI Portal (the input field label: "Cloud Extra Info"). The best practice to utilize this "cloud-extra-info" property is that ONAP users to input format json string, with
+which extra configuration data can be serialized as {"key":"value"} into this json string. And the corresponding MultiCloud plugin decode and utilize the input key-value pairs.