Propose automating multi-region on-boarding 97/56697/2
authorBin Yang <bin.yang@windriver.com>
Wed, 18 Jul 2018 10:15:27 +0000 (10:15 +0000)
committerBin Yang <bin.yang@windriver.com>
Tue, 14 Aug 2018 12:05:30 +0000 (12:05 +0000)
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>
docs/specs/multicloud-multi-region.rst [new file with mode: 0644]

diff --git a/docs/specs/multicloud-multi-region.rst b/docs/specs/multicloud-multi-region.rst
new file mode 100644 (file)
index 0000000..b67626f
--- /dev/null
@@ -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.