Separating the georedundancy use cases to separate files.

Small corrections to both georedundancy and progamable provisioning.

Change-Id: I8ec6eeece4cb94f5aae230ef1d25a1bb76fc9db4
Signed-off-by: csatari <gergely.csatari@nokia.com>

3 files changed, 54 insertions, 47 deletions

diff --git a/docs/requirements/use_cases/georedundancy.rst b/docs/requirements/use_cases/georedundancy_cells.rst
index 372230f..23fcb8d 100644
--- a/docs/requirements/use_cases/georedundancy.rst
+++ b/docs/requirements/use_cases/georedundancy_cells.rst
@@ -1,27 +1,30 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-Georedundancy Use cases (Draft)
-===============================
+Georedundancy: Connection between different OpenStack cells
+-----------------------------------------------------------
 Georedundancy refers to a configuration which ensures the service continuity of
 the VNF-s even if a whole datacenter fails [Q: Do we include or exclude VNF
 pooling?].
+
 This can be achieved by redundant VNF-s in a hot (spare VNF is running its
 configuration and internal state is synchronised to the active VNF),
 warm (spare VNF is running, its configuration is synchronised to the active VNF)
 or cold (spare VNF is not running, active VNF-s configuration is stored in a
 database and dropped to the spare VNF during its activation) standby state in a
 different datacenter from where the active VNF-s are running.
+The synchronisation and data transfer can be handled by the application or the infrastructure.
 In all of these georedundancy setups there is a need for a network connection
 between the datacenter running the active VNF and the datacenter running the
 spare VNF.
 
-This set of use cases is about enabling the possiblity to select a datacenter as
+In case of a distributed cloud it is possible that the georedundant cloud of an application
+is not predefined or changed and the change requires configuration in the underlay networks.
+
+This set of georedundancy use cases is about enabling the possiblity to select a datacenter as
 backup datacenter and build the connectivity between the NFVI-s in the
 different datacenters in a programmable way.
 
-Connection between different OpenStack cells
---------------------------------------------
 Description
 ^^^^^^^^^^^
 There should be an API to manage the infrastructure-s networks between two
@@ -60,40 +63,3 @@ Dependencies on compute services
 Potential implementation
 """"""""""""""""""""""""
    - TBD
-
-Connection between different OpenStack regions or cloud instances
------------------------------------------------------------------
-
-Description
-^^^^^^^^^^^
-There should be an API to manage the infrastructure-s networks between two
-OpenStack regions or between two OpenStack cloud instances.
-(The only difference is the shared keystone in case of a region)
-
-Requirements
-^^^^^^^^^^^^
-   - Possibility to define a remote and a local endpoint
-   - Possiblity to define an overlay/segregation technology
-
-Northbound API / Workflow
-"""""""""""""""""""""""""
-   - An infrastructure network management API is needed
-   - When the endpoints are created neutron is configured to use the new network.
-     (Note: Nova networking is not considered as it is deprecated.)
-
-
-Data model objects
-""""""""""""""""""
-   - TBD
-
-Orchestration
-"""""""""""""
-   - TBD
-
-Dependencies on compute services
-""""""""""""""""""""""""""""""""
-   - TBD
-
-Potential implementation
-""""""""""""""""""""""""
-   - TBD
diff --git a/docs/requirements/use_cases/georedundancy_regions_insances.rst b/docs/requirements/use_cases/georedundancy_regions_insances.rst
new file mode 100644
index 0000000..408b425
--- /dev/null
+++ b/docs/requirements/use_cases/georedundancy_regions_insances.rst
@@ -0,0 +1,39 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Georedundancy: Connection between different OpenStack regions or cloud instances
+--------------------------------------------------------------------------------
+
+Description
+^^^^^^^^^^^
+There should be an API to manage the infrastructure-s networks between two
+OpenStack regions or between two OpenStack cloud instances.
+(The only difference is the shared keystone in case of a region)
+
+Requirements
+^^^^^^^^^^^^
+   - Possibility to define a remote and a local endpoint
+   - Possiblity to define an overlay/segregation technology
+
+Northbound API / Workflow
+"""""""""""""""""""""""""
+   - An infrastructure network management API is needed
+   - When the endpoints are created neutron is configured to use the new network.
+     (Note: Nova networking is not considered as it is deprecated.)
+
+
+Data model objects
+""""""""""""""""""
+   - TBD
+
+Orchestration
+"""""""""""""
+   - TBD
+
+Dependencies on compute services
+""""""""""""""""""""""""""""""""
+   - TBD
+
+Potential implementation
+""""""""""""""""""""""""
+   - TBD
diff --git a/docs/requirements/use_cases/programmable_provisioning.rst b/docs/requirements/use_cases/programmable_provisioning.rst
index e08775b..eb9b6f5 100644
--- a/docs/requirements/use_cases/programmable_provisioning.rst
+++ b/docs/requirements/use_cases/programmable_provisioning.rst
@@ -14,16 +14,17 @@ It should be possible to assign the capability to create provider networks to an
 
 Derrived Requirements
 ~~~~~~~~~~~~~~~~~~~~~
-   - Possibility to assign the property of provider networks to any role
-   - When the provider network is created it should be checked if the role of the user has the permission to create a provider network.
+   - Authorize the possibility of provider network creation based on policy
+   - There should be a new entry in :code:`policy.json` which controls the provider network creation
+   - Default policy of this new enrty should be :code:`rule:admin_or_owner`.
 
 Northbound API / Workflow
 +++++++++++++++++++++++++
-   - TBD
+   - No changes in the API
 
 Data model objects
 ++++++++++++++++++
-   - TBD
+   - No changes in the data model
 
 Orchestration
 +++++++++++++
@@ -35,4 +36,5 @@ Dependencies on compute services
 
 Potential implementation
 ++++++++++++++++++++++++
-   - TBD
+   - Policy engine shall be able to handle a new provider network creation and modification related policy
+   - When a provider network is created or modified neutron should check the authority with the policy engine instead of requesting administrative rights