This is a summary of the main changes made to the Placement service in OpenStack, including only visible changes made to the placement service itself. This is cribbed from the commit history, but is only highlights, not a complete reckoning. There are plenty of other changes, both under the hood, and on the nova-side of the equation. Listing all that would make for a very long document. If a summary of the nova-side is desired, please ask.

Placement API Changes

A bug was fixed when updating allocations to prevent a 500 response if an empty set of resources was provided.

allocations was added to the list of links included in the resource providers representation. Initially identified by a bug.

The concept of a granular resource request syntax was partially implemented. This makes it possible to request resources in a more granular fashion as may be necessary in some situations with nested resource providers. The linked spec provides plenty of examples.

If a request does not provide an accept header, the service has been updated to default it to application/json. This ensures that all error responses have a standard (and structured) format. It was already the case that non-error responses would be JSON.

The format for GET and PUT of allocations was updated to be the same, and always be a dict-like structure. This allows easier and more consistent processing on the client side.

That new structure allowed for the creation of a POST to /allocations that allows an atomic action to manage allocations for multiple consumers in one request, supporting race-free migration allocations.

Nested resource provider information (root and parent) was added to the representation for /resource_providers and /resource_providers/{uuid} in a 1.14 microversion along with an in_tree query parameter to list the members of a tree of resource providers when provided with the UUID of one member of the tree.

The / URI in the Placement service no longer requires authentication. This helps support proper version discovery.

Entities in the Placement service now have minimal cache headers to prevent proxies and other HTTP clients doing inadvertent caching.

When requesting /allocation_candidates a limit parameter can be passed to constrain the number of allocation requests that are returned. This is designed to limit the amount of memory and bandwidth consumed by the scheduler. A config setting for the scheduler-side of the equation has been added.

A required parameter is added to GET /allocation_candidates enabling trait support. Resource providers will be filtered to only include those with the desired trait. Note: This functionality does not yet support reporting results in a form that is nested-resource-providers aware. That was something we hoped to get done in Queens but didn't quite make it.