Use in_tree getting allocation candidates

In Stein, we introduced in_tree=<rp_uuid> parameter in placement for the GET /allocation_candidates endpoints, which limits the response to resource providers within the same tree of the specified resource provider. (See the Filter Allocation Candidates by Provider Tree spec for details)

This spec proposes to use this parameter for optimization when we create or move instances and the target host is already picked before asking to the scheduler.

Problem description

In create and move instance operations, there are cases where the target host is already picked before calling the scheduler. Even in such cases, nova retrieves all the possible candidates from placement. This is inefficient and can cause, for example, Bug#1777591 filtering out the pre-determined target resource provider by Limiting Allocation Candidates feature in placement.

Use Cases

  • Creating an instance to a host specified by operator

  • Migrating an instance to a host specified by operator

  • Live-migrating an instance to a host specified by operator without forcing

  • Evacuating an instance to a host specified by operator without forcing

  • Rebuilding an instance in the same host with a new image.

Proposed change

Instead of issuing the inefficient request to placement, we will use in_tree query with the pre-determined target host resource provider uuid calling the GET /allocation_candidates API.


Disable the Limiting Allocation Candidates feature calling placement. This is actually what we have now as workaround, but not efficient. (See the unlimiting allocation candidates patch for details)

Data model impact

The RequestGroup object will have a new field, in_tree in the new version.

REST API impact


Security impact


Notifications impact


Other end user impact


Performance Impact

The performance would be improved because we don’t need to get all the candidates.

Other deployer impact

This spec is proposed on the assumption that the placement code in nova repository will be removed in Train release and that all the deployers will use the extracted placement from Train release. Note that in_tree queryparam to placement is not supported in placement hosted in nova.

Developer impact


Upgrade impact

We will have a minimum required placement API check in the nova-status upgrade checks command.



Primary assignee:


Work Items

  • Changes to support the new feature

    • Add in_tree field in RequestGroup object implementing the translation into the placement query parameter

    • Add a database query in the scheduler to translate RequestSpec.force_hosts/force_nodes and RequestSpec.requested_destination to the compute node uuid and set it to the new RequestGroup.in_tree field

  • Revert the workaround in unlimiting allocation candidates patch


The Filter Allocation Candidates by Provider Tree spec, but this has been completed in Stein.


Functional tests will be added to ensure the server operations described in the Use Cases section.

Documentation Impact