Open Stack

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 [1], he was after some input
from the api-sig.

We agreed that PUT to /v3/limits (and its friends) is probably not
ideal because:

* 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
do.


[1] http://p.anticdent.org/1G54

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent