<div dir="ltr">More comments inline.<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 31 July 2015 at 01:47, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The issue is that the Neutron credentials might not have privileges to resolve the name to a UUID. I suppose we could just fail in that case.<div><br></div></div></blockquote><div><br></div><div>As quota-update is usually restricted to admin users this should not be a problem, unless the deployment uses per-service admin users.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Let's see what happens with the nova spec Salvatore linked.</div></div></blockquote><div><br></div><div>That spec seems stuck to me. I think the reason is lack of reasons for raising its priority.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 30, 2015 at 4:33 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">If the quota update resolved the name to a uuid before it updated the quota by uuid, I think it would resolve the issues? You'd just have to check if keystone was in use, and then
 do the extra resolve on update. I think the rest of the stuff can just remain using uuids?<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Once you accept that it's not a big deal to do a round trip to keystone, then we can do whatever we want. If there is value from a API usability perspective we'll just do that.</div><div>If the issue is instead more the CLI UX, I would consider doing resolving the name (and possibly validating the tenant uuid) in python-neutronclient.</div><div><br></div><div>Also, I've checked the docs [1] and [2] and neutron quota-update is not supposed to accept tenant name - so probably the claim made in the initial post on this thread did not apply to neutron after all. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Kevin Benton [<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>]<br>
<b>Sent:</b> Thursday, July 30, 2015 4:22 PM<div><div><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug<br>
</div></div></font><br>
</div><div><div>
<div></div>
<div>
<div dir="ltr">Good point. Unfortunately the other issues are going to be the hard part to deal with. I probably shouldn't have brought up performance as a complaint at this stage. :)</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jul 30, 2015 at 3:26 AM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Can a non admin update quotas? Quota updates are rare. Performance of them can take the hit.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" size="2" color="#000000"> </font></div>
</strong>
<hr>
<font face="Tahoma" size="2"><b>From:</b> Kevin Benton<br>
<b>Sent:</b> Wednesday, July 29, 2015 10:44:49 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug<br>
</font>
<div>
<div><br>
<div></div>
<div>
<div dir="ltr">><span style="font-size:12.8000001907349px">Dev lessons learned: we need to validate better our inputs and refuse to update a tenant-id that does not exist.</span><br style="font-size:12.8000001907349px">
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">This is something that has come up in Neutron discussions before. There are two issues here: </span></div>
<div><span style="font-size:12.8000001907349px">1. Performance: it will require a round-trip to Keystone on every request.</span></div>
<div><span style="font-size:12.8000001907349px">2. If the Neutron keystone user in unprivileged and the request context is unprivileged, we might not actually be allowed to tell if the tenant exists.</span></div>
<div><br>
</div>
<div>The first we can deal with, but the second is going to be an issue that we might not be able to get around.</div>
<div><br>
</div>
<div>How about as a temporary solution, we just confirm that the input is a UUID so names don't get used?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 29, 2015 at 10:19 PM, Bruno L <span dir="ltr">
<<a href="mailto:teolupus.ext@gmail.com" target="_blank">teolupus.ext@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>This is probably affecting other people as well, so hopefully message will avoid some headaches.<br>
<br>
</div>
[nova,cinder,neutron] will allow you to do a quota-update using the tenant-name (instead of tenant-id). They will also allow you to do a quota-show tenant-name and get the expected values back.<br>
<br>
</div>
Then you go to the tenant and end up surprised that the quotas have not been applied and you can still do things you were not supposed to.<br>
<br>
</div>
It turns out that [nova,cinder,neutron] just created an entry on the quota table, inserting the tenant-name on the tenant-id field.<br>
<br>
</div>
<div>"Surprise, surprise!"<br>
</div>
<div><br>
</div>
Ops lessons learned: use the tenant-id!<br>
<br>
</div>
Dev lessons learned: we need to validate better our inputs and refuse to update a tenant-id that does not exist.<br>
<br>
</div>
I have documented this behaviour on <a href="https://bugs.launchpad.net/neutron/+bug/1399065" target="_blank">
https://bugs.launchpad.net/neutron/+bug/1399065</a> and <a href="https://bugs.launchpad.net/neutron/+bug/1317515" target="_blank">
https://bugs.launchpad.net/neutron/+bug/1317515</a>. I can reproduce it in IceHouse.<br>
<br>
</div>
Could someone please confirm if this is still the case on master? If not, which version of OpenStack addressed that?<br>
<br>
</div>
Thanks,<br>
</div>
Bruno<br>
</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>
<div>Kevin Benton</div>
</div>
</div>
</div>
</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>
<div>Kevin Benton</div>
</div>
</div>
</div>
</div></div></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><div>Kevin Benton</div></div>
</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></div></div></div>