diff options
author | Gergely Csatari <gergely.csatari@nokia.com> | 2016-05-13 11:11:27 +0200 |
---|---|---|
committer | Gerrit Code Review <gerrit@172.30.200.206> | 2016-05-22 18:09:24 +0000 |
commit | 44a200562ce1512867c3e8ad07ef57e046f15305 (patch) | |
tree | e4f9ca0dec57eef65610a7a2ba7243fa3317f572 /docs | |
parent | 7d08ea317d3de6c291e1fa8306d256a8b3a687f8 (diff) |
- Corrections based on the comments recived on the netready project meeting wk19
- Algnement of the section markups
- Some more questions :)
Change-Id: I0dc22f68ac501e5ae774178c6093190c2c584745
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/requirements/use_cases/georedundancy.rst | 74 |
1 files changed, 49 insertions, 25 deletions
diff --git a/docs/requirements/use_cases/georedundancy.rst b/docs/requirements/use_cases/georedundancy.rst index 513eee1..372230f 100644 --- a/docs/requirements/use_cases/georedundancy.rst +++ b/docs/requirements/use_cases/georedundancy.rst @@ -3,73 +3,97 @@ Georedundancy Use cases (Draft) =============================== +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. +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 +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 OpenStack cells. -(Note: In the Mitaka release of OpenStack cells v1 are considered as, cells v2 functionaity is under implementation) +^^^^^^^^^^^ +There should be an API to manage the infrastructure-s networks between two +OpenStack cells. +(Note: In the Mitaka release of OpenStack cells v1 are considered as, cells v2 +functionaity is under implementation) + +- Maybe the existing capability of Neutron to have several subnets associated + to an external network is enough? -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ +Requirements +^^^^^^^^^^^^ - Possibility to define a remote and a local endpoint - - Possiblity to define an overlay/segregation technology - - As in case of cells the nova-api service is shared it should be possible to identify the cell in the API calls + - As in case of cells the nova-api service is shared it should be possible + to identify the cell in the API calls 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.) + - 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 +"""""""""""""""""""""""""""""""" + None. 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. +^^^^^^^^^^^ +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) -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ +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.) + - 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 - |