Stackers,
Today, a few of us had a chat to discuss changes to the Placement REST
API [1] that will allow multiple clients to safely update a single
consumer's set of resource allocations. This email is to summarize the
decisions coming out of that chat.
Note that Ed is currently updating the following nova-spec:
https://review.openstack.org/#/c/556971/
The decisions made were as follows:
1) The GET /allocations/{consumer_uuid} REST API endpoint will now have
a required consumer_generation field in the response. This will be an
integer value.
2) The PUT /allocations/{consumer_uuid} REST API endpoint will have a
new consumer_generation required field in the request payload.
3) Callers to PUT /allocations/{consumer_uuid} that believe they are the
first caller to set allocations for the consumer will set
consumer_generation to None.
4) If consumer_generation is None in the request to PUT
/allocations/{consumer_uuid} and the placement service notes that
allocations already exist for that consumer, a 409 conflict will be
returned. The caller will need to then GET /allocations/{consumer_uuid}
to retrieve the consumer's current generation and allocations, merge its
new resources into those allocations and retry PUT
/allocations/{consumer_uuid}, passing the merged allocation set and
consumer generation.
5) The POST /allocations REST API endpoint is currently only used by
nova when performing migrate or resize operations for a virtual machine.
The POST /allocations REST API request payload will contain a new
required consumer_generation field in each top-level dict element
corresponding to the allocations to overwrite for one or more consumers.
(the migrate/resize code paths use multiple consumer UUIDs to identify
the resources that are allocated to the source and destination hosts)
6) The HTTP response codes for both PUT /allocations/{consumer_uuid} and
POST /allocations will continue to be 204 No Content.
Thanks,
-jay
[1] https://docs.openstack.org/nova/latest/user/placement.html
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
