Limiting Placement Allocation Candidates

Registered by Chris Dent

In a large and sparse cloud (e.g. 10,000 empty compute nodes), a request of GET /allocation_candidates?resource=VCPU:1 can return information for 10,000 resource providers. This has implications for memory and performance on both the placement service and in the client (in the present day, the nova-scheduler). To get around these concerns a 'limit' is proposed. A naive implementation of 'limit' will impact the pack or spread style of the cloud as the database will have a "natural" order that will put certain hosts first. To get around this an indexable column of randomness can be added to the db and the limited query can be sorted on that. If the values of that column are set only once, the cloud is biased to pack. If the values are updated regularly on a periodic job, the cloud is biased to spread.

Blueprint information

Dan Smith
Chris Dent
Chris Dent
Series goal:
Accepted for queens
Milestone target:
milestone icon queens-3
Started by
Matt Riedemann
Completed by
Matt Riedemann

Related branches



Gerrit topic:,topic:bp/allocation-candidates-limit,n,z

Addressed by:
    Spec for limiting GET /allocation_candidates

Spec was approved for Queens. -- mriedem 20171013

Addressed by:
    WIP: [placement] Enable limiting GET /allocation_candidates

We might want to consider moving the 'randomize results' config option to be it's own query parameter in the Rocky release so that different clients can determine if they want the results shuffled or not, e.g. Nova might want that, Cinder might not. Then the client-side configuration can determine those results, like if an operator configures the nova scheduler to not return a lot of results, they might want a random shuffle over those results whereas if they have a high limit, they might not want to make them random. We can discuss at the Rocky PTG in Dublin. -- mriedem 20180106


Work Items

This blueprint contains Public information 
Everyone can see this information.