From 673bf398bf6bf74f40aa8a41d8aa25e265fab9de Mon Sep 17 00:00:00 2001 From: csatari Date: Tue, 24 May 2016 10:34:35 +0200 Subject: Separating the georedundancy use cases to separate files. Small corrections to both georedundancy and progamable provisioning. Change-Id: I8ec6eeece4cb94f5aae230ef1d25a1bb76fc9db4 Signed-off-by: csatari --- docs/requirements/use_cases.rst | 3 +- docs/requirements/use_cases/georedundancy.rst | 99 ---------------------- .../requirements/use_cases/georedundancy_cells.rst | 65 ++++++++++++++ .../use_cases/georedundancy_regions_insances.rst | 39 +++++++++ .../use_cases/programmable_provisioning.rst | 12 +-- 5 files changed, 113 insertions(+), 105 deletions(-) delete mode 100644 docs/requirements/use_cases/georedundancy.rst create mode 100644 docs/requirements/use_cases/georedundancy_cells.rst create mode 100644 docs/requirements/use_cases/georedundancy_regions_insances.rst (limited to 'docs/requirements') 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.rst deleted file mode 100644 index 372230f..0000000 --- a/docs/requirements/use_cases/georedundancy.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. 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 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) - -- Maybe the existing capability of Neutron to have several subnets associated - to an external network is enough? - -Requirements -^^^^^^^^^^^^ - - Possibility to define a remote and a local endpoint - - 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.) - - -Data model objects -"""""""""""""""""" - - TBD - -Orchestration -""""""""""""" - - TBD - -Dependencies on compute services -"""""""""""""""""""""""""""""""" - 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. -(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_cells.rst b/docs/requirements/use_cases/georedundancy_cells.rst new file mode 100644 index 0000000..23fcb8d --- /dev/null +++ b/docs/requirements/use_cases/georedundancy_cells.rst @@ -0,0 +1,65 @@ +.. 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 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. + +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. + +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) + +- Maybe the existing capability of Neutron to have several subnets associated + to an external network is enough? + +Requirements +^^^^^^^^^^^^ + - Possibility to define a remote and a local endpoint + - 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.) + + +Data model objects +"""""""""""""""""" + - TBD + +Orchestration +""""""""""""" + - TBD + +Dependencies on compute services +"""""""""""""""""""""""""""""""" + None. + +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 -- cgit 1.2.3-korg