diff options
Diffstat (limited to 'docs/requirements')
| -rw-r--r-- | docs/requirements/use_cases.rst | 3 | ||||
| -rw-r--r-- | docs/requirements/use_cases/georedundancy_cells.rst (renamed from docs/requirements/use_cases/georedundancy.rst) | 50 | ||||
| -rw-r--r-- | docs/requirements/use_cases/georedundancy_regions_insances.rst | 39 | ||||
| -rw-r--r-- | docs/requirements/use_cases/programmable_provisioning.rst | 12 |
4 files changed, 56 insertions, 48 deletions
diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst index fd3a6f0..e4fc7d7 100644 --- a/docs/requirements/use_cases.rst +++ b/docs/requirements/use_cases.rst @@ -10,4 +10,5 @@ The following sections address networking use cases that have been identified to use_cases/l3vpn.rst use_cases/shared_service_functions.rst use_cases/programmable_provisioning.rst - use_cases/georedundancy.rst + use_cases/georedundancy_cells.rst + use_cases/georedundancy_regions_insances.rst 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 |