--- /dev/null
+..
+ This work is licensed under a Creative Commons Attribution 4.0
+ International License.
+
+=====================================================
+MultiCloud alignment to Consistent ID of Cloud Region
+=====================================================
+
+To support ONAP Functional Requirement: "Centralized Representation and Consistent Identification of Cloud Regions In ONAP", MultiCloud services have to upgrade their APIs to align to the consistent ID of a cloud region.
+..
+https://wiki.onap.org/display/DW/Centralized+Representation+and+Consistent+Identification+of+Cloud+Regions+In+ONAP
+
+Problems Statement
+==================
+
+With ONAP Amsterdam and Beijing Releases, there are 2 problems with respect to
+the ID of a cloud region.
+
+``Problem 1``: {vim_id}={cloud-owner}_{cloud-region-id} imposed unnecessary constraint
+on how {cloud-owner} can be populated: character underscore '_' cannot be used to
+populate {cloud-owner}
+
+``Problem 2``: multicloud plugins for OpenStack leverages {cloud-region-id} as the OpenStack
+Region ID to interact with represented OpenStack Instance. This implies that {cloud-region-id}
+can only be populated by the represented OpenStack Region ID. This constraint implies
+that two OpenStack instances with the same Region ID can only be represented with different
+{cloud-owner}, even though they belong to the same owner. This is a violation to the
+sematics of {cloud-owner} . on the other hand, the sematics of {cloud-region-id} refers to the
+geographic region, which is not necessarily the same as OpenStack Region ID. What's more, the
+fact that VID and SDNC have been using the {cloud-region-id} alone to identify a cloud region makes
+the problem being unacceptable.
+
+Proposed Solutions
+==================
+
+I would like to present 2 proposals to workaround each of problems above respectively:
+
+``Proposal 1: depreciate the {vim_id} for all multicloud services, use composed keys {cloud-owner},
+{cloud-region-id}``
+
+This will result in upgrading the multicloud APIs and code refactoring.
+
+We'd better to have common terminologies to facilitate the description below. Take the identity token API
+as example:
+
+::
+
+ http(s)://{service IP}:{service port}/api/multicloud/v0/{cloud-owner}_{cloud-region-id}/identity/v3/auth/tokens
+ e.g. http://1.2.3.4:9001/api/multicloud/v0/OnaplabOwner_RegionOne/identity/v3/auth/tokens
+
+
+This API consists of several parts referred as below terminologies:
+
+
+ - **Terminology | Description | Example**
+ - **service endpoint** | http(s)://{service IP}:{service port}| http://1.2.3.4:9001
+ - **service namespace** | api/{service-name} | api/multicloud
+ - **service API version** | v0, v1, etc. | v0
+ - **ID of a cloud region**| the ID to specify a cloud region| OnaplabOwner_RegionOne
+ - **proxied API catalog** | identity,compute, network, image,volume,etc.| identity
+ - **proxied API endpoint**| consists of all above| *http://1.2.3.4:9001/api/multicloud/v0/OnaplabOwner_RegionOne/identity*
+ - **proxied API resource**| URI for an OpenStack resource | v3/auth/tokens
+
+Given the terminology above, the general rules to upgrade MultiCloud North Bound API are:
+ - Upgrade "service API version" from "v0" to "v1"
+ - Change "ID of cloud region" from "{cloud-owner}_{cloud-region-id}" to "{cloud-owner}/{cloud-region-id}"
+
+The upgraded API for identity token API looks like:
+
+::
+
+ http(s)://{service IP}:{service port}/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/identity/v3/auth/tokens
+ e.g. http(s)://1.2.3.4:9001/api/multicloud/v1/OnaplabOwner/RegionOne/identity/v3/auth/tokens
+
+
+``Proposal 2: decouple the cloud region's {cloud-region-id} from OpenStack's Region ID``
+
+Instead of populating the AAI's cloud-region-id with OpenStack Region ID, decoupling of them by put OpenStack Region ID
+into other property of a cloud region object would enable the flexibility of populating arbitrary string to AAI's
+cloud-region-id. There are several options to implement that, with the intention of maintaining backward compatibility
+and minimized impact on AAI's schema, the proposed design options are described as below.
+
+Option 1: ONAP User inputs the OpenStack Region ID with ESR Portal
+
+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.
+..
+https://wiki.onap.org/pages/viewpage.action?pageId=25431491
+
+
+**This proposal changes and workflow With Option 1**:
+
+1. Define a key "openstack-region-id" with value populated by OpenStack Region ID,
+ e.g. "RegionOne", "RegionTwo", etc. which must align to the represented OpenStack instance.
+2. ONAP user should put this key-value pair into "cloud-extra-info" property via ESR GUI Portal, the input string
+ looks like: "{\"openstack-region-id\":\"RegionOne\"}"
+3. the corresponding MultiCloud plugin should decode this string to extract this key-value pair "openstack-region-id" during cloud region on-boarding phase.
+4, Update AAI schema to add one more property "openstack-region-id" to AAI "esr-system-info" object which is the child of AAI "cloud-region" object.
+5, MultiCloud plugin for OpenStack should populate this property with the information acquired in step 3.
+6, MultiCloud should use this property to determine what OpenStack Region ID is when interacting with represented OpenStack Instance
+7. Given the workflow above, the AAI's "cloud-region-id" can be populated by arbitrary string.
+8. In cases that either ONAP user doesn't input the key-value pair of "openstack-region-id" into "cloud-extra-info" or MultiCloud Plugin does not support the decoding/using key-value pair "openstack-region-id", the legacy constraint should be applied, that is: ONAP user should make sure AAI's "cloud-region-id" is populated by OpenStack Region ID.
+
+
+Option 2: MultiCloud plugin discover the OpenStack Region ID with Rest API
+
+The Identity API: "/v3/regions" can be used to list all regions. In case of no multi-region configuration for underlying OpenStack instance,
+this API should return the only one OpenStack Region information. In case of multi-region configuration for underlying OpenStack instances,
+The list of OpenStack Regions will be returned. In this case, I assume you either go with Option 1,
+or go with another proposal "MultiCloud Multi-Region support" to on-board all cloud regions at one time.
+
+..
+https://developer.openstack.org/api-ref/identity/v3/index.html#regions
+
+**This proposal changes and workflow With Option 2**:
+
+1, MultiCloud plugin for OpenStack discover the OpenStack region ID with Rest API during cloud region on-boarding phase.
+2, Update AAI schema to add one more property "openstack-region-id" to AAI "esr-system-info" object which is the child of AAI "cloud-region" object.
+3, MultiCloud plugin for OpenStack should populate this property with informatin acquired during step 1.
+4, MultiCloud should use this property to determine what OpenStack Region ID is when interacting with represented OpenStack Instance
+5. Given the workflow above, the AAI's "cloud-region-id" can be populated by arbitrary string.
--- /dev/null
+..
+ This work is licensed under a Creative Commons Attribution 4.0
+ International License.
+ Copyright (c) 2017-2018 Wind River Systems, Inc.
+
+==============================
+MultiCloud HEAT and AAI Bridge
+==============================
+
+This proposal describes how MultiCloud plugin automates the updating of HEAT stack resources into AAI after HEAT based VNF instantiation
+
+Problems Statement
+==================
+
+With heat template based VNF instantiation, SO interacts with target OpenStack instance directly (or indirectly via MultiCloud) to launch
+HEAT stacks. Once these HEAT stacks are created successfully, the ONAP users have to update the AAI with this HEAT stack resources manually
+by executing the ROBOT heatbridge script which not only imposes extra burden on ONAP users but also breaks the automating process of VNF orchestration.
+
+Considering that SO will integrate with MultiCloud in Casablanca Release, and the updating of AAI with HEAT stack resources demands no further
+interaction between SO and MultiCloud, neither any changes introduced to existing AAI schema. It is nature and elegant to automate this AAI updating process by MultiCloud plugin.
+
+https://wiki.onap.org/display/DW/Vetted+vFirewall+Demo+-+Full+draft+how-to+for+F2F+and+ReadTheDocs?src=contextnavpagetreemode
+
+
+Proposed Design and Workflow
+============================
+
+**This automation assumes**:
+ - SO integrates with multicloud so that the heat based VNF will be instantiated to an OpenStack Instance indirectly via MultiCloud.
+ - SO will pass on the generic VNF ID and/or VF Module ID to MultiCloud.
+ - ONAP user will not execute the ROBOT heatbridge script any more.
+
+
+**The proposed changes to MultiCloud Broker and Plugins**
+ - Add a new northbound API, e.g. POST /api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload , the request body is a json object consists of generic vnf id, vf module id, heat template, heat env file, and other parameters, e.g. oof selected flavors
+ - MultiCloud Broker distribute this API request to corresponding MultiCloud Plugin
+ - MultiCloud Plugin will validate the request with input data, call OpenStack HEAT API to launch HEAT stacks, and updating AAI with the launched HEAT stack resource, and associate these resource to generic VNF/VF-Module Objects.
+
+**Updated AAI objects**
+ - /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/tenants/tenant/{tenant-id}/vservers/vserver/{vserver-id}
+ - /network/generic-vnfs/generic-vnf/{vnf-id}/vf-modules/vf-module/{vf-module-id}
+
+
+Appendix:
+=========
+
+https://wiki.onap.org/display/DW/AAI+REST+API+Documentation+-+Beijing
--- /dev/null
+..
+ 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.
--- /dev/null
+..
+ This work is licensed under a Creative Commons Attribution 4.0
+ International License.
+
+======================================================
+MultiCloud security enhancement: secured communication
+======================================================
+
+To support an ONAP Non-Functional Requirement with regarding to Security: "All internal/external system communications shall be able to be encrypted", MultiCloud project needs to explore the best way to implement it.
+
+..
+https://wiki.onap.org/display/DW/Casablanca+Release+Requirements#CasablancaReleaseRequirements-NonFunctionalRequirements
+
+Problems Statement
+==================
+
+By default all MultiCloud micro-services expose APIs with non-secured endpoints. To fulfill the ONAP security requirement above, either MultiCloud integrate with AAF's CADI SDK or leverage some other technology.
+ - Integration with AAF's CADI is preferred by the security subcommittee, however, this requires AAF team or someone provides CADI SDK in python binding. So far there is no promising resource to do that and no roadmap yet.
+ - On the other hands, ISTIO's security feature could fulfill this requirement very well without imposing any modification of MultiCloud source code. MSB project team is exploring the way to implement it for OOM based ONAP deployment.
+
+
+One caveat is that ISTIO approach is only applicable to OOM based ONAP deployment. Hence the question would be:
+Whether we should implement this feature for HEAT based ONAP deployment? And if yes, how?
+
+Proposed Solutions
+==================
+
+1, **With respect to HEAT based ONAP deployment**:
+
+Given the consensus achieved during ONAP Casablanca Forum, HEAT based ONAP deployment is only for Integration test,
+and the fact that many other features are only applicable to OOM based ONAP deployment, I do think it does not hurt to decide
+that MultiCloud enable this security feature only for OOM based ONAP deployment.
+So the answer to the questions above would be: We will not implement this security feature for HEAT based ONAP deployment
+
+2, **With respect to OOM based ONAP deployment**:
+
+it is intended that MultiCloud project will collaborate with MSB project and VFC project to implement this security feature with the approach of ISTIO.
+
+MultiCloud does not need to change anything, but need to pay attention to following facts:
+ - The deployment of the PODs of micro-services: MSB,VFC,MultiCloud will be deployed into seperated kubernetes namespace other than the one for those not utilizing ISTIO features.
+ - All communication across different kubernetes namespace should use either IP or FQDN (Full Qualified Domain Name)
+
+
+Test Use Cases
+==================
+
+The pariwise and integration testing will be conducted between VFC and MultiCloud in context of VoLTE or vCPE use case.
+
BUILD_ARGS="--no-cache"
ORG="onap"
-VERSION="1.1.2-SNAPSHOT"
-STAGING_VERSION="1.1.2-STAGING"
+VERSION="1.2.0-SNAPSHOT"
+STAGING_VERSION="1.2.0-STAGING"
PROJECT="multicloud"
IMAGE="framework"
DOCKER_REPOSITORY="nexus3.onap.org:10003"
<parent>
<groupId>org.onap.multicloud.framework</groupId>
<artifactId>multicloud-framework</artifactId>
- <version>1.1.2-SNAPSHOT</version>
+ <version>1.2.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.onap.multicloud.framework.broker</groupId>
<artifactId>multicloud-framework-broker</artifactId>
- <version>1.1.2-SNAPSHOT</version>
+ <version>1.2.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>multicloud-framework-broker</name>
<description>multivim broker</description>
<modelVersion>4.0.0</modelVersion>
<groupId>org.onap.multicloud.framework</groupId>
<artifactId>multicloud-framework</artifactId>
- <version>1.1.2-SNAPSHOT</version>
+ <version>1.2.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>multicloud-framework</name>
<description>multivim broker</description>
# because they are used in Jenkins, whose plug-in doesn't support
major=1
-minor=1
-patch=2
+minor=2
+patch=0
base_version=${major}.${minor}.${patch}
Code Review / multicloud / framework.git / commitdiff