Open Stack

hi Duncan
Sorry for the long delay.   IMHO, the purpose of this change is let the
cinder have ability to control admin's action. If admin only want to limit
the users not to create resources any more, fine, use the option argument
'"skip_validation=False" to update the quota limit and just equal the usage
of current quota is ok, do not allow lower than it.  On the other hand, If
admin clearly know what he is doing and want to set a new quota limit of
tenant, ok, use the "skip_validation=True" to update the quota lower than
current usage and tell user "I've updated a new quota limit for you, now
delete some resource to get under it."

I agree that admin should be educated to know what they want to do and use
a proper argument to reduce the confusion that was brought to end user.

2015-07-13 18:21 GMT+08:00 Duncan Thomas <duncan.thomas at gmail.com>:

> 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
>
> __________________________________________________________________________
> 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/20150719/fae62eba/attachment.html>