summaryrefslogtreecommitdiffstats
path: root/docs/requirements/use_cases
diff options
context:
space:
mode:
authorGeorg Kunz <georg.kunz@ericsson.com>2016-11-01 00:56:10 +0100
committerGeorg Kunz <georg.kunz@ericsson.com>2016-11-04 12:49:59 +0100
commitf29faf9e0f22dccfe0e4ad32ccff733341d43e4d (patch)
tree2ed5249aa1afcff3f0f3facb25a282a259f75b7c /docs/requirements/use_cases
parent58607a9a71aba724acaa0aa31659379e762f76e8 (diff)
Retiring the "provisioning of provider networks" use case
The gap identified along with this use case has been addressed ini the upstream community. Hence, moving to this use case to a separate section of the requirements document. Change-Id: I9cd95f1128a9845cda4ec42fe1692f22cdc03a9d Signed-off-by: Georg Kunz <georg.kunz@ericsson.com>
Diffstat (limited to 'docs/requirements/use_cases')
-rw-r--r--docs/requirements/use_cases/images/api-users.pngbin21271 -> 0 bytes
-rw-r--r--docs/requirements/use_cases/programmable_provisioning.rst52
2 files changed, 0 insertions, 52 deletions
diff --git a/docs/requirements/use_cases/images/api-users.png b/docs/requirements/use_cases/images/api-users.png
deleted file mode 100644
index 1f08812..0000000
--- a/docs/requirements/use_cases/images/api-users.png
+++ /dev/null
Binary files differ
diff --git a/docs/requirements/use_cases/programmable_provisioning.rst b/docs/requirements/use_cases/programmable_provisioning.rst
deleted file mode 100644
index 963451d..0000000
--- a/docs/requirements/use_cases/programmable_provisioning.rst
+++ /dev/null
@@ -1,52 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Programmable Provisioning of Provider Networks
-----------------------------------------------
-Description
-~~~~~~~~~~~
-
-In a NFV environment the VNFMs (Virtual Network Function Manager) are consumers
-of the OpenStack IaaS API. They are often deployed without administrative rights
-on top of the NFVI platform. Furthermore, in the telco domain provider networks
-are often used. However, when a provider network is created administrative
-rights are needed what in the case of a VNFM without administrative rights
-requires additional manual configuration work. It shall be possible to
-configure provider networks without administrative rights. It should be
-possible to assign the capability to create provider networks to any roles.
-
-The following figure (:numref:`api-users`) shows the possible users of an
-OpenStack API and the relation of OpenStack and ETSI NFV components. Boxes with
-solid line are the ETSI NFV components while the boxes with broken line are the
-OpenStack components.
-
-.. figure:: images/api-users.png
- :name: api-users
- :width: 50%
-
-Derived Requirements
-~~~~~~~~~~~~~~~~~~~~~
- - 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 entry should be :code:`rule:admin_or_owner`.
- - This policy should be respected by the Neutron API
-
-Northbound API / Workflow
-+++++++++++++++++++++++++
- - No changes in the API
-
-Data model objects
-++++++++++++++++++
- - No changes in the data model
-
-Current implementation
-~~~~~~~~~~~~~~~~~~~~~~
-Only admin users can manage provider networks [OS-NETWORKING-GUIDE-ML2]_.
-
-Potential implementation
-~~~~~~~~~~~~~~~~~~~~~~~~
- - 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.