Merge "Spec: support any trait in allocation candidates"
This commit is contained in:
commit
795d4e2950
|
@ -0,0 +1,197 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=================================================
|
||||||
|
Support any traits in allocation_candidates query
|
||||||
|
=================================================
|
||||||
|
|
||||||
|
https://storyboard.openstack.org/#!/story/2005346
|
||||||
|
|
||||||
|
The ``GET /allocation_candidates`` request in Placement supports the
|
||||||
|
``required`` query parameter. If the caller specifies a list of traits in the
|
||||||
|
``required`` parameter then placement will limit the returned allocation
|
||||||
|
candidates to those RP trees that fulfill *every* traits in that list. To
|
||||||
|
support minimum bandwidth guarantees in Neutron + Nova we need to be able to
|
||||||
|
query allocation candidates that fulfill *at least one* trait from a list of
|
||||||
|
traits specified in the query. This is required for the case when a Neutron
|
||||||
|
network maps to more than one physnets but the port's bandwidth request can be
|
||||||
|
fulfilled from any physnet the port's network maps to.
|
||||||
|
|
||||||
|
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
|
||||||
|
provided in the 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.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Extend the ``GET /allocation_candidates`` and ``GET /resource_providers``
|
||||||
|
requests with a new ``required=in:TRAIT1,TRAIT2`` query parameter syntax and
|
||||||
|
change the placement implementation to support this new syntax.
|
||||||
|
|
||||||
|
The `granular-resource-requests`_ spec proposes support for multiple request
|
||||||
|
groups in the Placement query identified by a positive integer postfix in the
|
||||||
|
``required`` query param. The new ``in:TRAIT1,TRAIT2`` syntax is applicable to
|
||||||
|
the ``required<N>`` query params as well.
|
||||||
|
|
||||||
|
.. _`granular-resource-requests`: https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/granular-resource-requests.html
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
During the train review Sean suggested to use ``any``, ``all``, ``none``
|
||||||
|
instead of using the currently proposed ``in:`` syntax. However to keep the API
|
||||||
|
consistent we decided to continue using ``in:`` for traits as it is already
|
||||||
|
used for aggregates. Still we think that ``any``, ``all``, ``none`` would be a
|
||||||
|
better syntax but that requires a separate effort changing the existing query
|
||||||
|
syntax as well.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
Today the ``GET /allocation_candidates`` and ``GET /resource_providers`` query
|
||||||
|
support the ``required`` query param in the form of
|
||||||
|
``required=TRAIT1,TRAIT2,!TRAIT3``. This spec proposes to implement a new
|
||||||
|
microversion to allow the format of ``required=in:TRAIT1,TRAIT2`` as well
|
||||||
|
as the old format.
|
||||||
|
|
||||||
|
Each resource provider returned from a request having
|
||||||
|
``required=in:TRAIT1,TRAIT2`` should have *at least* one matching trait from
|
||||||
|
TRAIT1 and TRAIT2.
|
||||||
|
|
||||||
|
``required=in:TRAIT1,TRAIT2`` used in a ``GET /allocation_candidates`` query
|
||||||
|
means that the union of all the traits across all the providers in every
|
||||||
|
allocation candidate must contain at least one of T1, T2.
|
||||||
|
|
||||||
|
``requiredX=in:TRAIT1,TRAIT2`` used in a ``GET /allocation_candidates`` query
|
||||||
|
means that the resource provider that satisfies the requirement of the granular
|
||||||
|
request group ``X`` must also has at least one of T1, T2.
|
||||||
|
|
||||||
|
The response body of the ``GET /allocation_candidates`` and
|
||||||
|
``GET /resource_providers`` query are unchanged.
|
||||||
|
|
||||||
|
A separate subsequent spec will propose to support repeating the ``required``
|
||||||
|
query param more than once to allow mixing the two formats.
|
||||||
|
|
||||||
|
Note that mixing required and forbidden trait requirements in the same
|
||||||
|
``required=in:`` query param, like ``required=in:TRAIT1,!TRAIT2`` will not be
|
||||||
|
supported and will result a HTTP 400 response.
|
||||||
|
|
||||||
|
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. That plugin currently support the --required CLI
|
||||||
|
parameter accepting a list of traits. So this patch propose to extend that
|
||||||
|
parameter to accept in:TRAIT1,TRAIT2 format.
|
||||||
|
|
||||||
|
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 the
|
||||||
|
new type of query
|
||||||
|
* Extend the Placement REST API with a new microversion that supports the any
|
||||||
|
trait syntax
|
||||||
|
* Extend the osc-placement client plugin to support the new microversion
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
* the osc-placement client plugin can only be extended with the new
|
||||||
|
microversion support if every older microversion is already supported which
|
||||||
|
is not the case today.
|
||||||
|
|
||||||
|
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
|
||||||
|
==========
|
||||||
|
|
||||||
|
* osc-placement `review`_ series adding support for latest Placement
|
||||||
|
microversions
|
||||||
|
|
||||||
|
.. _`review`: https://review.openstack.org/#/c/548326
|
||||||
|
|
||||||
|
|
||||||
|
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
|
Loading…
Reference in New Issue