[openstack-dev] [keystone] batch processing with unified limits
cdent+os at anticdent.org
Fri Mar 9 18:05:13 UTC 2018
On Wed, 7 Mar 2018, Lance Bragstad wrote:
> Currently, the create and update APIs support batch processing. So
> specifying a list of limits is valid for both. This was a part of the
> original proposal as a way to make it easier for operators to set all
> their registered limits with a single API call. The API also has unique
> IDs for each limit reference. The consensus was that this felt a bit
> weird with a resource that contains a unique set of attributes that can
> make up a constraints (service, resource type, and optionally a region).
> We're discussing ways to make this API more consistent with how the rest
> of keystone works while maintaining usability for operators. Does anyone
> see issues with supporting batch creation for limits and individual
> updates? In other words, removing the ability to update a set of limits
> in a single API call, but keeping the ability to create them in batches?
Lance and I spoke about this in IRC , he was after some input
from the api-sig.
We agreed that PUT to /v3/limits (and its friends) is probably not
* It's not aligned with how PUT is used elsewhere in keystone.
* In order for the PUT to be correct (according to HTTP rules) it would
have to be an entire set updating all the limits, even those that
haven't changed, and this could be large and annoying. PUT to
update one limit is cleaner.
* While POSTs to create all the limits are quite voluminous, any
changes to existing limits are likely to be smaller, thus the cost
of non-batch updates by individual PUTs is not as severe.
* PATCH is still available if batch updates are desired, but doing
PATCH well and correctly is challenging.
So we agreed that given that the API is currently experimental,
changing it to not support batch PUT is probably a right thing to
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
More information about the OpenStack-dev