Open Stack

The problem is, if you reject the request to lower quota unless the usage
is under the new quota, you've got an inherently racy process where the
admin needs to communicate with the tenant to say 'Stop using some of your
quota while I reduce it', which is no less complicated than 'I've reduced
your quota, now delete some resources to get under it'. It honestly sounds
like the right thing to do here is to educate the admins who are surprised
by the current behaviour, rather than to introduce a new behaviour that is
fundamentally no better.

On 13 July 2015 at 12:14, hao wang <sxmatch1986 at gmail.com> wrote:

> Hi, Mike
>
> I'm not sure we really don't need any change about this feature. At least,
> some end users I faced to think there should be changed....
>
> IMHO, there is a main problem that some users whom I faced to can't
> understand: What's the purpose that admin reduce quota lowner than existing
> usage? Limit user to can't create any resources any more? But why reduce
> quota just equal the current usage, it has same function. Make user to
> delete their resources lower than the new limit line? It's weak if user
> don't want to do that deletion and also bring some confusion to other users
> that I have mentioned.
>
> I understood there may be 100 reasons to show me why admin can reduce the
> quota lower than usage, and I don't want to object them too. But I hope
> this change can bring some new usage to update quota: 1. When admin use
> client(could be third party) to update the quota limit, they should check
> quota usage first as winston mentioned, if they don't or forget, anyway,
> they will change failed if quota is lower than usage, since we give the
> ability to cinder it will stop them to do that thing and make admin back to
> check quota usage. 2. If admin know what they are doing and just need to
> reduce the limit lower for some reason, fine, take the option argument
> '--force' or '--skip_validation' to update the quota.
>
> In personally, I felt this routine may be more improvement and little
> confusion with it. I knew Eric said that of course we can implement this
> purpose by using current APIs, it's a alternatives, but it depends on the
> application which is top on cinder I think, and is hard to have consistent.
>
> 2015-07-11 7:24 GMT+08:00 Mike Perez <thingee at gmail.com>:
>
>> On 12:30 Jul 10, hao wang 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.
>>
>> Based on the feedback received in the bug and review, it seems like there
>> is
>> a clear consensus that people don't want this, even if it can be bypassed
>> with
>> a force option.
>>
>> --
>> Mike Perez
>>
>> __________________________________________________________________________
>> 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!
>
>
> __________________________________________________________________________
> 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
>
>


-- 
-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150713/0c234ed8/attachment.html>