osc placement allocation-candidate list

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.

You can also find additional case studies of the request parameters in the Modeling with Provider Trees document.

Normal Response Codes: 200

Error response codes: badRequest(400)

Usage: osc placement allocation-candidate list [OPTIONS]

Options:

  • --group-policy <GROUP_POLICY> — When more than one resourcesN query parameter is supplied, group_policy is required to indicate how the groups should interact. With group_policy=none, separate groupings - with or without a suffix - may or may not be satisfied by the same provider. With group_policy=isolate, suffixed groups are guaranteed to be satisfied by different providers - though there may still be overlap with the suffixless group
  • --in-tree <IN_TREE> — A string representing a resource provider uuid. When supplied, it will filter the returned allocation candidates to only those resource providers that are in the same tree with the given resource provider
  • --limit <LIMIT> — A positive integer used to limit the maximum number of allocation candidates returned in the response
  • --member-of <MEMBER_OF> — A string representing an aggregate uuid; or the prefix in: followed by a comma-separated list of strings representing aggregate uuids. The resource providers in the allocation request in the response must directly or via the root provider be associated with the aggregate or aggregates identified by uuid: member_of=5e08ea53-c4c6-448e-9334-ac4953de3cfa, member_of=in:42896e0d-205d-4fe3-bd1e-100924931787,5e08ea53-c4c6-448e-9334-ac4953de3cfa Starting from microversion 1.24 specifying multiple member_of query string parameters is possible. Multiple member_of parameters will result in filtering providers that are directly or via root provider associated with aggregates listed in all of the member_of query string values. For example, to get the providers that are associated with aggregate A as well as associated with any of aggregates B or C, the user could issue the following query: member_of=AGGA_UUID&member_of=in:AGGB_UUID,AGGC_UUID Starting from microversion 1.32 specifying forbidden aggregates is supported in the member_of query string parameter. Forbidden aggregates are prefixed with a !. This negative expression can also be used in multiple member_of parameters: member_of=AGGA_UUID&member_of=!AGGB_UUID would translate logically to “Candidate resource providers must be in AGGA and not in AGGB.” We do NOT support ! on the values within in:, but we support !in:. Both of the following two example queries return candidate resource providers that are NOT in AGGA, AGGB, or AGGC: member_of=!in:AGGA_UUID,AGGB_UUID,AGGC_UUID, member_of=!AGGA_UUID&member_of=!AGGB_UUID&member_of=!AGGC_UUID We do not check if the same aggregate uuid is in both positive and negative expression to return 400 BadRequest. We still return 200 for such cases. For example: member_of=AGGA_UUID&member_of=!AGGA_UUID would return empty allocation_requests and provider_summaries, while: member_of=in:AGGA_UUID,AGGB_UUID&member_of=!AGGA_UUID would return resource providers that are NOT in AGGA but in AGGB
  • --required <REQUIRED> — A comma-separated list of traits that a provider must have: required=HW_CPU_X86_AVX,HW_CPU_X86_SSE Allocation requests in the response will be for resource providers that have capacity for all requested resources and the set of those resource providers will collectively contain all of the required traits. These traits may be satisfied by any provider in the same non-sharing tree or associated via aggregate as far as that provider also contributes resource to the request. Starting from microversion 1.22 traits which are forbidden from any resource provider contributing resources to the request may be expressed by prefixing a trait with a !. Starting from microversion 1.39 the required query parameter can be repeated. The trait lists from the repeated parameters are AND-ed together. So: required=T1,!T2&required=T3 means T1 and not T2 and T3. Also starting from microversion 1.39 the required parameter supports the syntax: required=in:T1,T2,T3 which means T1 or T2 or T3. Mixing forbidden traits into an in: prefixed value is not supported and rejected. But mixing a normal trait list and an in: prefixed trait list in two query params within the same request is supported. So: required=in:T3,T4&required=T1,!T2 is supported and it means T1 and not T2 and (T3 or T4)
  • --resources <RESOURCES> — A comma-separated list of strings indicating an amount of resource of a specified class that providers in each allocation request must collectively have the capacity and availability to serve: resources=VCPU:4,DISK_GB:64,MEMORY_MB:2048 These resources may be satisfied by any provider in the same non-sharing tree or associated via aggregate
  • --root-required <ROOT_REQUIRED> — A comma-separated list of trait requirements that the root provider of the (non-sharing) tree must satisfy: root_required=COMPUTE_SUPPORTS_MULTI_ATTACH,!CUSTOM_WINDOWS_LICENSED Allocation requests in the response will be limited to those whose (non-sharing) tree’s root provider satisfies the specified trait requirements. Traits which are forbidden (must not be present on the root provider) are expressed by prefixing the trait with a !
  • --same-subtree <SAME_SUBTREE> — A comma-separated list of request group suffix strings ($S). Each must exactly match a suffix on a granular group somewhere else in the request. Importantly, the identified request groups need not have a resources[$S]. If this is provided, at least one of the resource providers satisfying a specified request group must be an ancestor of the rest. The same_subtree query parameter can be repeated and each repeat group is treated independently