Bin Yang | 9e3eaba | 2018-07-18 10:15:27 +0000 | [diff] [blame] | 1 | .. |
| 2 | This work is licensed under a Creative Commons Attribution 4.0 |
| 3 | International License. |
| 4 | Copyright (c) 2017-2018 Wind River Systems, Inc. |
| 5 | |
| 6 | =============================== |
| 7 | MultiCloud Multi-Region support |
| 8 | =============================== |
| 9 | |
| 10 | This proposal describes how MultiCloud plugin automates the on-boarding of tens or hundreds of cloud regions by leveraging multi-region feature |
| 11 | |
| 12 | Problems Statement |
| 13 | ================== |
| 14 | |
| 15 | The ONAP functional requirement for Edge Automation aims to automate the VNF orchestration across edge stacks. |
Bin Yang | 9e3eaba | 2018-07-18 10:15:27 +0000 | [diff] [blame] | 16 | .. |
| 17 | https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP |
| 18 | |
| 19 | 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 |
| 20 | all secondary regions' endpoints. Hence MultiCloud plugins could automate the discovery and registry |
| 21 | of all OpenStack secondary regions. |
| 22 | |
| 23 | |
| 24 | Proposed Design and Workflow |
| 25 | ============================ |
| 26 | |
Victor Morales | a2dcefa | 2018-08-27 11:37:06 -0700 | [diff] [blame] | 27 | This automation assumes: |
Bin Yang | 9e3eaba | 2018-07-18 10:15:27 +0000 | [diff] [blame] | 28 | - ONAP could use the same set of credentials (project, user/password) to access all OpenStack regions for orchestration. |
| 29 | - ONAP user will explicitly enable the automation of discovery OpenStack secondary regions during manually on-boarding the OpenStack primary region. |
| 30 | - ONAP users could manually manage the cloud regions representing those secondary regions just like a normal cloud region |
| 31 | |
| 32 | |
Victor Morales | a2dcefa | 2018-08-27 11:37:06 -0700 | [diff] [blame] | 33 | With OpenStack primary region, the ONAP user will: |
Bin Yang | 9e3eaba | 2018-07-18 10:15:27 +0000 | [diff] [blame] | 34 | .. |
| 35 | https://wiki.onap.org/pages/viewpage.action?pageId=25431491 |
Victor Morales | a2dcefa | 2018-08-27 11:37:06 -0700 | [diff] [blame] | 36 | |
Bin Yang | 9e3eaba | 2018-07-18 10:15:27 +0000 | [diff] [blame] | 37 | - Manually on-board this primary region with ESR VIM registration portal. |
| 38 | - Input the {cloud-owner} and {cloud-region-id} as the ID of cloud region which is unique. |
| 39 | - Specify the location id |
| 40 | - 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" |
| 41 | |
| 42 | |
| 43 | **With OpenStack primary region, the corresponding MultiCloud plugin will**: |
| 44 | - Discover all OpenStack secondary regions in case being explicitly indicated with key-value pair {"multi-region-discovery":"true"} |
| 45 | - Register each of discovered OpenStack regions as a new cloud region into AAI. |
| 46 | - Duplicate the credentials and location relationship from primary region. |
| 47 | - Duplicate all or part of the cloud region's property "cloud-extra-info", |
| 48 | - Add one more key-value pair to cloud region's property "cloud-extra-info": {"primary-region":["{cloud-owner}","{cloud-region-id}"]} |
| 49 | - Add relationship to the cloud region of primary region: to be checked. |
| 50 | - Generate the ID of cloud region representing the OpenStack secondary region with following rules: |
| 51 | - {cloud-owner} should be {cloud-owner of primary region}. |
| 52 | - {cloud-region-id} will be the concatenated string with format: {cloud-region-id of primary region}.{OpenStack Region ID}. |
| 53 | - 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. |
| 54 | |
| 55 | |
| 56 | **With generated cloud region representing the OpenStack secondary region, the ONAP user could**: |
| 57 | - update the credentials so that the ONAP could use updated credentials to orchestrate VNF to this cloud region |
| 58 | - update the location of the cloud region by associating it to different complex object other than the one same to primary region. |
| 59 | - Update cloud region's property "cloud-extra-info". |
| 60 | - Decommission or delete the cloud region |
| 61 | |
| 62 | |
| 63 | Appendix: |
| 64 | ========= |
| 65 | |
| 66 | There is a property of cloud region object named "cloud-extra-info" |
| 67 | .. |
| 68 | https://wiki.onap.org/display/DW/AAI+REST+API+Documentation+-+Beijing |
| 69 | |
| 70 | :: |
| 71 | |
| 72 | cloud-extra-info: string |
| 73 | ESR inputs extra information about the VIM or Cloud which will be decoded by MultiVIM. |
| 74 | |
| 75 | 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 |
| 76 | 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 |
| 77 | 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. |