Open Stack

Hi, Duncan

As Gorka said, we are trying not to impact default API behavior, just give
a choice to client that it can restrict cloud admin to update quota lower
than current usage.

2015-07-10 16:47 GMT+08:00 Duncan Thomas <duncan.thomas at gmail.com>:

> 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" <geguileo at 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" <sxmatch1986 at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best Wishes For You!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150710/27db1f42/attachment.html>