<div dir="ltr">To the best of my knowledge Neutron is unable to enforce tenant quotas using the tenant name; this should be "undocumented".<div>What Kevin suggests also goes in this direction, even if we have to be careful as we're making assumptions on how tenant ids are represented (if the deployment is not using Keystone, for instance, they could be anything).<br><div><br></div><div>Quotas are enforce by checking the tenant_id for which a resource is being created is not already using all its quota of this resource.</div><div>Neutron does not have any logic for resolving the tenant name into its identifier in this process.</div><div><br></div><div>The validation of the tenant identifier is something that goes beyond quota management. Users with admin credentials can create networks and other resources for random tenants that do not exist. Validation of the tenant id might make sense, but, as Kevin said, must be performed by Keystone. Therefore in order to avoid an extra round trip I would personally try and perform this task in the keystonemiddleware step (the one that does authentication too).</div><div><br></div><div>Nevertheless there is a deferred nova spec [1] and patch [2] aiming at performing exactly what's asked for here - validating the tenant id when setting up quotas. I personally think we should seek a solution for validating the tenant_id for every request (if the operator wishes to do so).</div><div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/validate-tenant-user-with-keystone.html">http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/validate-tenant-user-with-keystone.html</a></div><div>[2] <a href="https://review.openstack.org/#/c/143934/">https://review.openstack.org/#/c/143934/</a><br><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 July 2015 at 07:44, 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"><span class="">><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></span><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"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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></div></div>__________________________________________________________________________<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><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</font></span></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>