[openstack-dev] [Openstack][Network] A question of quotas

Salvatore Orlando sorlando at nicira.com
Tue May 21 18:27:52 UTC 2013


Hi all,

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.

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
Port Quota checking is bypassed for these operation.
To prove this I did the following:
1) reduce port_quota in quantum.conf to 10
2) creates 6 network, 6 subnets and attach them to a router
As a result the tenant own 12 ports (6 dhcp + 6 router), and the quota is
already exceeded.
New ports can't be created via API (and nova), but attaching subnets to
routers keeps adding ports without problems.

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?
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.

Bug:
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).
The above would be easy.

Design issue:
if these ports should count for quotas, the API layer should perform the
quota check also for operations which will indirectly create a port.
This is not terribly difficult, but it would probably require to change a
thing or two in the base controller.

Thanks in advance for your comments,
Salvatore
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130521/675e0065/attachment.html>


More information about the OpenStack-dev mailing list