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.
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
History¶
Release Name |
Description |
|---|---|
Rocky |
Introduced |
Stein |
Reproposed, approved but not implemented |
Train |
Reproposed but not approved due to lack of focus |
Yoga |
Reproposed |
