<div dir="ltr">Hi, Duncan<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-10 16:47 GMT+08:00 Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Ah, I apologise, I missed the but where it defaults to force=true. I withdraw the objection.</p>
<p dir="ltr">I've no strung feelings about the change either way, in that case.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 10 Jul 2015 10:58, "Gorka Eguileor" <<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 10, 2015 at 10:28:06AM +0300, Duncan Thomas wrote:<br>
> That is a semantic change to the api that will break anybody who has<br>
> tooling expecting the current behavior. Since there are perfectly sensible<br>
> uses of the current behavior, that is not a good thing.<br>
<br>
Hi Duncan,<br>
<br>
I don't think that will be the case, if it's an optional argument that<br>
by default preserves current behavior (force = True), then it shouldn't<br>
break anything for all callers that don't use that new option.<br>
<br>
And for those that want the new behavior, they can always pass force set<br>
to false.<br>
<br>
Cheers,<br>
Gorka.<br>
<br>
> On 10 Jul 2015 07:33, "hao wang" <<a href="mailto:sxmatch1986@gmail.com" target="_blank">sxmatch1986@gmail.com</a>> wrote:<br>
><br>
> > Cinder now doesn't check the existing resource when user lower the quota.<br>
> > It's reasonable for admin can adjust the quota limit to lower level than<br>
> > current usage.<br>
> > But it also bring confusion that I have received to end user, they saw the<br>
> > current usage<br>
> > was more than limit, but they can't create resources any more.<br>
> ><br>
> > So there have been 'bug' reported[1] and code patch[2] committed, I knew<br>
> > it may be<br>
> > inappropriate as 'bug fix', but just want to optimize this API of<br>
> > updating quota.<br>
> ><br>
> > We are proposing to add an option argument which is named 'force' in<br>
> > request body.<br>
> > Of course the default value is True that means admin can adjust the quota<br>
> > lower then<br>
> > current usage as same as what we did now. When the force is False, that<br>
> > will occur<br>
> > a Validation and return 400 Bad Request if the update value is lower than<br>
> > current usage.<br>
> ><br>
> > I wonder to know folks' opinions and suggestions about this change to see<br>
> > if this is value to merge this patch.<br>
> ><br>
> > [1]<a href="https://bugs.launchpad.net/neutron/+bug/1304234" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1304234</a><br>
> > [2]<a href="https://review.openstack.org/#/c/197938/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/197938/</a><br>
> ><br>
> > Thanks~<br>
> ><br>
> > --<br>
> ><br>
> > Best Wishes For You!<br>
> ><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><pre>Best Wishes For You!</pre></div>
</div>