summaryrefslogtreecommitdiffstats
path: root/docs/specs
diff options
context:
space:
mode:
authorVictor Morales <victor.morales@intel.com>2018-08-27 11:37:06 -0700
committerVictor Morales <victor.morales@intel.com>2018-08-27 11:37:06 -0700
commita2dcefabf7239c4687c3ab01e03796e017211285 (patch)
tree951f37189a19f4607deb9d462f74cf81f728d020 /docs/specs
parentbc4187f075e89b200393babb3d89b207513b5dd1 (diff)
Use python rstcheck to validate syntax
Given that this repository contains multiple documents for specifications is necessary to implement a mechanism to validate its syntax. The rstchecker tool ensures that it meets the reStructured Text guidelines. Change-Id: I6a5d30c78718ae83265f9302f3d514eacaff2ae1 Issue-ID: DOC-300 Signed-off-by: Victor Morales <victor.morales@intel.com>
Diffstat (limited to 'docs/specs')
-rw-r--r--docs/specs/logging_enablement.rst2
-rw-r--r--docs/specs/multicloud-cloud-region-id.rst23
-rw-r--r--docs/specs/multicloud-multi-region.rst6
-rw-r--r--docs/specs/multicloud-secured-communication.rst1
4 files changed, 15 insertions, 17 deletions
diff --git a/docs/specs/logging_enablement.rst b/docs/specs/logging_enablement.rst
index 1ec3df7..9f89443 100644
--- a/docs/specs/logging_enablement.rst
+++ b/docs/specs/logging_enablement.rst
@@ -74,7 +74,7 @@ MDC context specific logging, able to
change configuration at runtime, and make logging quite fast.
Supporting Python3 version
--------------------------
+--------------------------
Right now, this library only has be used in Python2 version. Python2 will not been
maintained after 2020, besides part of ONAP project have used python3 version.
It's be better to support Python2 and Python3 version
diff --git a/docs/specs/multicloud-cloud-region-id.rst b/docs/specs/multicloud-cloud-region-id.rst
index ea6d6a9..d132c49 100644
--- a/docs/specs/multicloud-cloud-region-id.rst
+++ b/docs/specs/multicloud-cloud-region-id.rst
@@ -52,14 +52,14 @@ as example:
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
+ - **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"
@@ -105,9 +105,9 @@ https://wiki.onap.org/pages/viewpage.action?pageId=25431491
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
+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.
@@ -118,7 +118,6 @@ The Identity API: "/v3/regions" can be used to list all regions. In case of no m
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
diff --git a/docs/specs/multicloud-multi-region.rst b/docs/specs/multicloud-multi-region.rst
index b67626f..cabd110 100644
--- a/docs/specs/multicloud-multi-region.rst
+++ b/docs/specs/multicloud-multi-region.rst
@@ -13,7 +13,6 @@ 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
@@ -25,15 +24,16 @@ of all OpenStack secondary regions.
Proposed Design and Workflow
============================
-**This automation assumes**:
+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**:
+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
diff --git a/docs/specs/multicloud-secured-communication.rst b/docs/specs/multicloud-secured-communication.rst
index 31956f3..722e86b 100644
--- a/docs/specs/multicloud-secured-communication.rst
+++ b/docs/specs/multicloud-secured-communication.rst
@@ -7,7 +7,6 @@ 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