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) --- docs/requirements/index.rst | 1 + docs/requirements/retired_use_cases.rst | 12 ++++ .../retired_use_cases/images/api-users.png | Bin 0 -> 21271 bytes .../programmable_provisioning.rst | 78 +++++++++++++++++++++ docs/requirements/use_cases.rst | 3 +- docs/requirements/use_cases/images/api-users.png | Bin 21271 -> 0 bytes .../use_cases/programmable_provisioning.rst | 52 -------------- 7 files changed, 92 insertions(+), 54 deletions(-) create mode 100644 docs/requirements/retired_use_cases.rst create mode 100644 docs/requirements/retired_use_cases/images/api-users.png create mode 100644 docs/requirements/retired_use_cases/programmable_provisioning.rst delete mode 100644 docs/requirements/use_cases/images/api-users.png delete mode 100644 docs/requirements/use_cases/programmable_provisioning.rst diff --git a/docs/requirements/index.rst b/docs/requirements/index.rst index a72ad99..21147bd 100644 --- a/docs/requirements/index.rst +++ b/docs/requirements/index.rst @@ -50,5 +50,6 @@ NetReady: Network Readiness introduction.rst use_cases.rst + retired_use_cases.rst summary.rst references.rst diff --git a/docs/requirements/retired_use_cases.rst b/docs/requirements/retired_use_cases.rst new file mode 100644 index 0000000..60df07b --- /dev/null +++ b/docs/requirements/retired_use_cases.rst @@ -0,0 +1,12 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Retired Use Cases +================= + +The following use cases have previously been analyzed in terms of gaps. Since +then, the identified gaps have been addressed and/or closed in the upstream +community. + +.. toctree:: + retired_use_cases/programmable_provisioning.rst 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. diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst index d31bbd3..b323593 100644 --- a/docs/requirements/use_cases.rst +++ b/docs/requirements/use_cases.rst @@ -1,7 +1,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -Use cases +Use Cases ========= The following sections address networking use cases that have been identified to be relevant in the scope of NFV and NetReady. @@ -10,5 +10,4 @@ The following sections address networking use cases that have been identified to use_cases/multiple_backends.rst use_cases/l3vpn.rst use_cases/service_binding_pattern.rst - use_cases/programmable_provisioning.rst use_cases/georedundancy.rst 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 Binary files a/docs/requirements/use_cases/images/api-users.png and /dev/null 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. -- cgit 1.2.3-korg