placement/placement-api-ref/source/allocation_candidates.inc

73 lines
2.1 KiB
PHP
Raw Normal View History

=====================
Allocation candidates
=====================
.. note:: Allocation candidates API requests are availiable starting from version 1.10.
List allocation candidates
==========================
Returns a dictionary representing a collection of allocation requests
and resource provider summaries. Each allocation request has
information to form a ``PUT /allocations/{consumer_uuid}`` request to claim
resources against a related set of resource providers. Additional parameters
might be required, see `Update allocations`_. As several allocation
requests are available it's necessary to select one. To make a
decision, resource provider summaries are provided with the
inventory/capacity information. For example, this information is used by
nova-scheduler's FilterScheduler to make decisions about on which compute host
to build a server.
.. rest_method:: GET /allocation_candidates
Normal Response Codes: 200
Error response codes: badRequest(400)
Request
-------
.. rest_parameters:: parameters.yaml
- resources: resources_query_required
[placement] Enable limiting GET /allocation_candidates This adds a limit query parameter to GET /allocation_candidates?limit=5&resource=VCPU:1 A 'limit' filter is added to the AllocationCandidates. If set, after the database query has been run to create the allocation requests and provider summaries, a slice or sample of the allocation requests is taken to limit the results. The summaries are then filtered to only include those in the allocation requests. This method avoids needing to make changes to the generated SQL, the creation of which is fairly complex, or the database tables. The amount of data queried is still high in the extreme case, but the amount of data sent over the wire (as JSON) is shrunk. This is a trade-off that was discussed in the spec and the discussion surrounding its review. If it turns out that memory use server-side is an issue we can investigate changing the SQL. A configuration setting, [placement]/randomize_allocation_candidates, is added to allow deployers to declare whether they want the results to be returned in whatever order the database chooses or a random order. The default is "False" which is expected to preserve existing behavior and impose a packing placement strategy. When the config setting is combined with the limit parameter, if "True" the limited results are a random sampling from the full results. If "False", it is a slice from the front. This is done as a new microversion, 1.16, with updates to docs, a reno and adjustments to the api history doc. Change-Id: I5f3d4f49c34fd3cd6b9d2e12b3c3c4cdcb409bec Implements: bp allocation-candidates-limit
2017-11-19 12:09:38 +00:00
- limit: allocation_candidates_limit
- required: allocation_candidates_required
Response (microversions 1.12 - )
--------------------------------
.. rest_parameters:: parameters.yaml
- allocation_requests: allocation_requests
- provider_summaries: provider_summaries
- allocations: allocations_by_resource_provider
- resources: resources
- capacity: capacity
- used: used
Response Example (microversions 1.12 - )
----------------------------------------
.. literalinclude:: get-allocation_candidates-1.12.json
:language: javascript
Response (microversions 1.10 - 1.11)
------------------------------------
.. rest_parameters:: parameters.yaml
- allocation_requests: allocation_requests
- provider_summaries: provider_summaries
- allocations: allocations_array
- resource_provider: resource_provider_object
- uuid: resource_provider_uuid
- resources: resources
- capacity: capacity
- used: used
Response Example (microversions 1.10 - 1.11)
--------------------------------------------
.. literalinclude:: get-allocation_candidates.json
:language: javascript