Re: [openstack-dev] [keystone] batch processing with unified limits
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__ 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
Re: [openstack-dev] [keystone] batch processing with unified limits
On 03/07/2018 06:10 PM, Lance Bragstad wrote: The keystone team is parsing the unified limits discussions from last week. One of the things we went over as a group was the usability of the current API [0]. 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? I suspect this would cover the typical usecases we have for standing up new clouds or a new service within a cloud. Chris __ 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
[openstack-dev] [keystone] batch processing with unified limits
The keystone team is parsing the unified limits discussions from last week. One of the things we went over as a group was the usability of the current API [0]. 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? We were talking about this in the keystone channel, but opening this up on the ML to get more feedback from other people who were present in those discussions last week. [0] https://developer.openstack.org/api-ref/identity/v3/index.html#unified-limits [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-07.log.html#t2018-03-07T22:49:46 signature.asc Description: OpenPGP digital signature __ 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
