![Eric Fried](/assets/img/avatar_default.png)
The API reference for POST /allocations [1] and PUT /allocations/{consumer_uuid} [2] specifically mentions that you can get a 409 on provider/inventory conflict. In microversion 1.28, it also became possible to get a 409 on an allocation (consumer generation) conflict. In the process of adding that information, it became evident that we weren't doing a good job explaining the whole generation thing in general, so this commit also adds a descriptive section to the front matter of the API reference. Links are included from the updated descriptions for the two affected allocations operations. Future commits can add links from other appropriate sections of the reference (e.g. the parameters.yaml entries for resource provider and consumer generation fields). Future commits could also enhance the descriptions of error codes for other operations to (at least) the level of detail at which these have ended up. [1] https://developer.openstack.org/api-ref/placement/?expanded=manage-allocations-detail#manage-allocations [2] https://developer.openstack.org/api-ref/placement/?expanded=update-allocations-detail#update-allocations Change-Id: I42e76785e0fe456b107fe843dbb242f2c5f5b9f7 Story: #2006180 Task: #35705
49 lines
2.1 KiB
PHP
49 lines
2.1 KiB
PHP
.. _generations:
|
|
|
|
==========================================
|
|
Resource Provider and Consumer Generations
|
|
==========================================
|
|
Placement handles concurrent requests against the same entity by maintaining a
|
|
**generation** for resource providers and consumers. The generation is an
|
|
opaque value that is updated every time its entity is successfully changed on
|
|
the server.
|
|
|
|
At appropriate microversions, the generation is returned in responses involving
|
|
resource providers and/or consumers (allocations), and must be included in
|
|
requests which make changes to those entities. The server checks to make sure
|
|
the generation specified in the request matches the internal value. A mismatch
|
|
indicates that a different request successfully updated that entity in the
|
|
interim, thereby changing its generation. This will result in an HTTP 409
|
|
Conflict response with `error code <error_codes_>`_
|
|
``placement.concurrent_update``.
|
|
|
|
Depending on the usage scenario, an appropriate reaction to such an error may
|
|
be to re-``GET`` the entity in question, re-evaluate and update as appropriate,
|
|
and resubmit the request with the new payload.
|
|
|
|
The following pseudocode is a simplistic example of how one might ensure that a
|
|
trait is set on a resource provider.
|
|
|
|
.. note:: This is not production code. Aside from not being valid syntax for
|
|
any particular programming language, it deliberately glosses over
|
|
details and good programming practices such as error checking, retry
|
|
limits, etc. It is purely for illustrative purposes.
|
|
|
|
::
|
|
|
|
function _is_concurrent_update(resp) {
|
|
if(resp.status_code != 409) return False
|
|
return(resp.json()["errors"][0]["code"] == "placement.concurrent_update")
|
|
}
|
|
|
|
function ensure_trait_on_provider(provider_uuid, trait) {
|
|
do {
|
|
path = "/resource_providers/" + provider_uuid + "/traits"
|
|
get_resp = placement.GET(path)
|
|
payload = get_resp.json()
|
|
if(trait in payload["traits"]) return
|
|
payload["traits"].append(trait)
|
|
put_resp = placement.PUT(path, payload)
|
|
} while _is_concurrent_update(put_resp)
|
|
}
|