Ah, I apologise, I missed the but where it defaults to force=true. I withdraw the objection.
I've no strung feelings about the change either way, in that case. On 10 Jul 2015 10:58, "Gorka Eguileor" <gegui...@redhat.com> wrote: > On Fri, Jul 10, 2015 at 10:28:06AM +0300, Duncan Thomas wrote: > > That is a semantic change to the api that will break anybody who has > > tooling expecting the current behavior. Since there are perfectly > sensible > > uses of the current behavior, that is not a good thing. > > Hi Duncan, > > I don't think that will be the case, if it's an optional argument that > by default preserves current behavior (force = True), then it shouldn't > break anything for all callers that don't use that new option. > > And for those that want the new behavior, they can always pass force set > to false. > > Cheers, > Gorka. > > > On 10 Jul 2015 07:33, "hao wang" <sxmatch1...@gmail.com> wrote: > > > > > Cinder now doesn't check the existing resource when user lower the > quota. > > > It's reasonable for admin can adjust the quota limit to lower level > than > > > current usage. > > > But it also bring confusion that I have received to end user, they saw > the > > > current usage > > > was more than limit, but they can't create resources any more. > > > > > > So there have been 'bug' reported[1] and code patch[2] committed, I > knew > > > it may be > > > inappropriate as 'bug fix', but just want to optimize this API of > > > updating quota. > > > > > > We are proposing to add an option argument which is named 'force' in > > > request body. > > > Of course the default value is True that means admin can adjust the > quota > > > lower then > > > current usage as same as what we did now. When the force is False, that > > > will occur > > > a Validation and return 400 Bad Request if the update value is lower > than > > > current usage. > > > > > > I wonder to know folks' opinions and suggestions about this change to > see > > > if this is value to merge this patch. > > > > > > [1]https://bugs.launchpad.net/neutron/+bug/1304234 > > > [2]https://review.openstack.org/#/c/197938/ > > > > > > Thanks~ > > > > > > -- > > > > > > Best Wishes For You! > > > > > > > > > > __________________________________________________________________________ > > > 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 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 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 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