From aed90244a9a355e0de93e8e33d2a4b0e70c41049 Mon Sep 17 00:00:00 2001 From: Manpreet Kaur Date: Thu, 17 Mar 2022 17:07:08 +0530 Subject: [PATCH] Enhance multi tenant policy in VNF LCM An enhancement of the multi-tenant policy in the VNF lifecycle management. * Discussion to enable a non-admin role user to instantiate VNF. * Add design for negative functional test cases for VNF LCM operations and validate notification is received by the tenant specified in the subscription sequence. Implements: bp enhance-multi-tenant-policy Change-Id: Idf398ea9bf083afdecb99a0cea3c539a34ec17d3 --- specs/zed/enhance-multi-tenant-policy.rst | 182 ++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 specs/zed/enhance-multi-tenant-policy.rst diff --git a/specs/zed/enhance-multi-tenant-policy.rst b/specs/zed/enhance-multi-tenant-policy.rst new file mode 100644 index 00000000..bf59a330 --- /dev/null +++ b/specs/zed/enhance-multi-tenant-policy.rst @@ -0,0 +1,182 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + http://creativecommons.org/licenses/by/3.0/legalcode + + +======================================================= +Enhance Multi-tenant policy in VNF Lifecycle Management +======================================================= +https://blueprints.launchpad.net/tacker/+spec/enhance-multi-tenant-policy + +This specification discusses the enhancement of multi-tenant policy in the +VNF lifecycle management. + +Discussion to enable a non-admin role user to instantiate VNF, tenancy +isolation between admin and the non-admin role users. + +Problem description +=================== + +In tacker, a non-admin role user is able to get resource information +for VNF, but fails to perform certain VNF LCM operations such as VNF +instantiation. + +Second, need to implement negative functional test cases for VNF LCM +operations and validate notification is received by the tenant specified +in the subscription sequence. + +Proposed change +=============== + +1. Allow non admin role user to instantiate VNF +----------------------------------------------- + +In OpenStack Heat Orchestration Template (HOT) enables the creation of most +OpenStack resource types, such as instances, floating IP addresses, volumes, +security groups and users, collectively known as the stack creation process. + +.. note:: By default admin role user is allowed to create an OpenStack stack. + +To allow non-admin role users to create VNFs, the OpenStack resource policies +must be changed. + +Below mention policies require necessitates change: + +#. Heat Policies + + * resource_types:OS::Nova::Flavor + * resource_types:OS::Cinder::VolumeType + * resource_types:OS::Neutron::QoSPolicy + * resource_types:OS::Neutron::QoSBandwidthLimitRule + +#. Nova Policies + + * os_compute_api:os-flavor-manage + * os_compute_api:os-flavor-manage:create + * os_compute_api:os-flavor-manage:delete + +#. Neutron Policies + + * create_policy + * create_policy_bandwidth_limit_rule + +.. note:: As per the investigation, OpenStack allows admin role users to create + stack, creation process involves different OpenStack services (such as Heat, + Nova, Glance, etc.). + + To enable a non-admin role user requires the above mention policy changes + as well as code level changes in desired OpenStack services as well. + + Adjourning investigation for this cycle, in future we can resume. + +2. Design for negative functional test cases +-------------------------------------------- + +The functional test case architecture for a multi-tenant environment, +as described in spec [#ADD-MTPOLICY]_, dedicates a subscription notification +server for each tenant. Validates that these servers only receive alerts +of VNF package or LCM operations conducted by their respective tenants. + +To address the design requirement, multiple instances of a fake HTTP server +was created, one for each tenant, to function as notification servers. +In Zuul, the fake HTTP server class instances run on the same test node +(controller-tacker). +In single tenancy, the desired HTTP requests and responses are fabricated(mock) +in functional test cases. +Similarly in a multi-tenant environment, mock HTTP requests and responses for +notification servers, with additional validation of tenant details present in +notification. + +Alternatives +------------ + +An alternate approach to designing a negative functional test case in Zuul, +where two distinct nodes are needed to construct notification servers. + +This approach has the following design/implementation challenges: + +* Adding two new Zuul nodes with a specific port open (opening a port in Zuul + may necessitate a special request). + +* On the new nodes, use ansible-playbook or similar to set up an HTTP server. + +* A network issue may cause the actual HTTP request to timeout. + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +None + +Developer impact +---------------- + +None + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Manpreet Kaur + +Work Items +---------- + +* Identify and enable the OpenStack policies that allow non admin role + users to create VNF. +* Add negative functional test cases for VNF LCM operations and validate + notification is received by the tenant specified in the subscription + sequence. + +Dependencies +============ + +None + +Testing +======= + +Functional tests will be added to cover cases required in the spec. + +Documentation Impact +==================== + +None + +References +========== + +.. [#ADD-MTPOLICY] https://specs.openstack.org/openstack/tacker-specs/specs/yoga/multi-tenant-policy.html