<div dir="ltr"><div>Hi Salvatore, <br><br>Makes sense to me. I agree, I don't think that the
 service ports (i.e gateway attachment/router-interfaces) should count 
against the quota. I think that making the policy layer aware of 
device_owner starts with 'networks': makes sense. One thing we'd need to
 make sure we enforce is that these service ports are actually onces 
that were created via a router-interface-add. Meaning we don't want someone to be able to do quantum port-create --device-owner network:router_interface or be able to update the device_owner of ports to get around the quota. What do you think about adding an attribute to ports (not to the api but in the db) service_port = <true/false> (or something like that)? <br>
<br></div>Aaron<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 21, 2013 at 11:27 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">Hi all,<div><br></div><div>A colleague of mine showed me an interesting behaviour of quantum quotas, and I am totally ashamed to say I did not have a straight answer for him. Perhaps you can help me.</div>

<div><br></div><div>Quantum has several API operations which trigger more or less directly the creation of a port. For instance: PUT /v2.0/routers/<id>/add_router_interface</div><div>Port Quota checking is bypassed for these operation.<br>

</div><div>To prove this I did the following:</div><div>1) reduce port_quota in quantum.conf to 10</div><div>2) creates 6 network, 6 subnets and attach them to a router</div><div>As a result the tenant own 12 ports (6 dhcp + 6 router), and the quota is already exceeded.</div>

<div>New ports can't be created via API (and nova), but attaching subnets to routers keeps adding ports without problems.</div><div><br></div><div>At first I thought that this was intended behaviour, since 'service' ports should not count toward the quota; but on the other hand they are taken into account when the API checks current usage with get_ports_count. Is this still desired behaviour?</div>

<div>I think there might be either a bug or a design issue, but I would like to confirm with people that are more expert than me with quotas, both from a user and a developer perspective.<br></div><div><br></div>
<div>Bug:</div><div>If 'service' ports should not be counted, ports whose device_owner starts with 'network:' should not be counted when validating quota availability. (Note: must include adv svcs too - eg: quantum:LOADBALANCER). </div>

<div>The above would be easy.</div><div><br></div><div>Design issue:</div><div>if these ports should count for quotas, the API layer should perform the quota check also for operations which will indirectly create a port.</div>

<div>This is not terribly difficult, but it would probably require to change a thing or two in the base controller.</div><div><br></div><div>Thanks in advance for your comments,</div><div>Salvatore</div>
<div><b><br></b></div>







</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>