OpenStack resource provider inventory allocation service
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

197 lines
5.9 KiB

This work is licensed under a Creative Commons Attribution 3.0 Unported
Support any traits in allocation_candidates query
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`:
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
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
``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
Notifications impact
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
Other deployer impact
Developer impact
Upgrade impact
Primary assignee:
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
* 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.
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.
* osc-placement `review`_ series adding support for latest Placement
.. _`review`:
.. 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