a09defd661
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)
|
|
}
|