From fb71123aa1fa589e2b7a015c453b2b5040ba7d0a Mon Sep 17 00:00:00 2001 From: Chris Dent Date: Tue, 2 Apr 2019 16:19:47 +0100 Subject: [PATCH] Spec: support mixing required traits with any traits This is a reproposal of a nova spec to placement, originally proposed in I9695f0cb2c0263cd0e8ca552d3a9dd720690e466. Previously-Approved: Stein Story: 2005345 Task: 30295 Change-Id: Ibada21dcabbb3824c8d9fdb7584d45abf844be68 --- ...mixing-required-traits-with-any-traits.rst | 204 ++++++++++++++++++ 1 file changed, 204 insertions(+) create mode 100644 doc/source/specs/yoga/approved/2005345-placement-mixing-required-traits-with-any-traits.rst diff --git a/doc/source/specs/yoga/approved/2005345-placement-mixing-required-traits-with-any-traits.rst b/doc/source/specs/yoga/approved/2005345-placement-mixing-required-traits-with-any-traits.rst new file mode 100644 index 000000000..ed6005742 --- /dev/null +++ b/doc/source/specs/yoga/approved/2005345-placement-mixing-required-traits-with-any-traits.rst @@ -0,0 +1,204 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +============================================== +Support mixing required traits with any traits +============================================== + +https://storyboard.openstack.org/#!/story/2005345 + +The `any-traits-in-allocation-candidates-query`_ spec proposed to allow +querying traits in the form of ``required=in:TRAIT1,TRAIT2``. This spec goes +one step further and proposes to allow repeating the ``required`` query +parameter to support mixing both ``required=TRAIT1,TRAIT2,!TRAIT3`` and +``required=in:TRAIT1,TRAIT2`` format in a single query. This is needed for +Neutron to be able to express that a port needs a resource provider having +a specific ``vnic_type`` trait but also having one of the physnet traits the +port's network maps to. + +For example:: + + GET /allocation_candidates?required1=CUSTOM_VNIC_TYPE_DIRECT& + required1=in:CUSTOM_PHYSNET_FOO,CUSTOM_PHYSNET_BAR + ... + +requests a networking device RP in the candidates that supports the ``direct`` +``vnic_type`` and is connected either to ``physnet_foo`` or ``physnet_bar`` or +both. + +Problem description +=================== + +Neutron through Nova needs to be able to query Placement for allocation +candidates that are matching to *at least one* trait from the list of traits as +well as matching another specific trait in a single query. + +Use Cases +--------- + +Neutron wants to use this any(traits) query to express that a port's bandwidth +resource request needs to be fulfilled by a Network device RP that is connected +to one of the physnets the network of the given port is connected to. With +Neutron's multiprovider network extension a single Neutron network can consist +of multiple network segments connected to different physnets. But at the same +time Neutron wants to express that the same RP has a specific vnic_type trait +as well. + +Proposed change +=============== + +Extend the ``GET /allocation_candidates`` and ``GET /resource_providers`` +requests to allow repeating the ``required`` and ``required`` query param +to support both the ``required=TRAIT1,TRAIT2,!TRAIT3`` and +``required=in:TRAIT1,TRAIT2`` syntax in a single query. + +Alternatives +------------ + +None + +Data model impact +----------------- + +None + +REST API impact +--------------- + +In a new microversion the ``GET /allocation_candidates`` and the +``GET /resource_providers`` query should allow repeating the ``required`` +query parameter more than once while supporting both normal and any trait +syntax in the same query. + +The ``GET /allocation_candidates`` query having +``required=CUSTOM_VNIC_TYPE_NORMAL& +required=in:CUSTOM_PHYSNET1,CUSTOM_PHYSNET2`` parameters should result in +allocation candidates where each allocation candidate has the traits +``CUSTOM_VNIC_TYPE_NORMAL`` and either ``CUSTOM_PHYSNET1`` or +``CUSTOM_PHYSNET2`` (or both). + +The ``GET /resource_providers`` query having +``required=CUSTOM_VNIC_TYPE_NORMAL& +required=in:CUSTOM_PHYSNET1,CUSTOM_PHYSNET2`` parameters should result in +resource providers where each resource provider has the traits +``CUSTOM_VNIC_TYPE_NORMAL`` and either ``CUSTOM_PHYSNET1`` or +``CUSTOM_PHYSNET2`` (or both). + +The response body of the ``GET /allocation_candidates`` and +``GET /resource_providers`` query are unchanged. + +Note the following two queries express exactly the same requirements:: + + ?required=in:A,B,C + &required=X + &required=Y + &required=Z + + ?required=in:A,B,C + &required=X,Y,Z + + +.. note:: + To ease the implementation we might decide to implement this API change in + the same microversion as `any-traits-in-allocation-candidates-query`_ + implemented in. + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +The osc-placement client plugin needs to be updated to support the new +Placement API microversion. This means the the CLI should support providing +the ``--required`` parameter more than once supporting both normal and any +trait syntax. + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +None + +Developer impact +---------------- + +None + +Upgrade impact +-------------- + +None + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + balazs-gibizer + +Work Items +---------- + +* Extend the resource provider and allocation candidate DB query to support + more than one set of required traits +* Extend the Placement REST API with a new microversion that supports repeating + the ``required`` query param +* Extend the osc-placement client plugin to support the new microversion + +Dependencies +============ + +* The `any-traits-in-allocation-candidates-query`_ spec + +.. _`any-traits-in-allocation-candidates-query`: https://review.openstack.org/649992 + +Testing +======= + +Both new gabbi and functional tests needs to be written for the Placement API +change. Also the osc-placement client plugin will need additional functional +test coverage. + +Documentation Impact +==================== + +The Placement API reference needs to be updated. + +References +========== + +None + +History +======= + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Rocky + - Introduced + * - Stein + - Reproposed, approved but not implemented + * - Train + - Reproposed but not approved due to lack of focus + * - Yoga + - Reproposed