From 01b644db5e301278aa4ab8863f8d439eb5a75b90 Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Tue, 1 Nov 2016 00:56:10 +0100 Subject: 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 (cherry picked from commit f29faf9e0f22dccfe0e4ad32ccff733341d43e4d) --- .../retired_use_cases/images/api-users.png | Bin 0 -> 21271 bytes .../programmable_provisioning.rst | 78 +++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 docs/requirements/retired_use_cases/images/api-users.png create mode 100644 docs/requirements/retired_use_cases/programmable_provisioning.rst (limited to 'docs/requirements/retired_use_cases') diff --git a/docs/requirements/retired_use_cases/images/api-users.png b/docs/requirements/retired_use_cases/images/api-users.png new file mode 100644 index 0000000..1f08812 Binary files /dev/null and b/docs/requirements/retired_use_cases/images/api-users.png differ diff --git a/docs/requirements/retired_use_cases/programmable_provisioning.rst b/docs/requirements/retired_use_cases/programmable_provisioning.rst new file mode 100644 index 0000000..7cb2e00 --- /dev/null +++ b/docs/requirements/retired_use_cases/programmable_provisioning.rst @@ -0,0 +1,78 @@ +.. 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% + + +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. + + +Solution in upstream community +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A bug report has been submitted to the upstream OpenStack community to highlight +this gap: +https://bugs.launchpad.net/neutron/+bug/1630880 + +This bug report revealed that this use case has already been addressed in the +upstream community. Specifically, it is possible to specify the roles (e.g., +admin, regular user) in the Neutron policy.json file which are able to create +and update provider networks. + +However, the OpenStack user guide wrongly stated that **only** administrators +can create and update provider type networks. Hence, a correction has been +submitted to the OpenStack documentation repository, clarifying the possibility +to change this behavior based on policies: +https://review.openstack.org/#/c/390359/ + +In conclusion, this use case has been retired as the corresponding gaps have been +closed in the upstream community. -- cgit 1.2.3-korg