Auto-created ports count against port quota

Bug #1212338 reported by Jay Pipes
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
neutron
Expired
Wishlist
Unassigned

Bug Description

Ports that are created for a new network -- lots of them by my experience (one for the L3 agent the tenant router is assigned to and one port for each compute worker in the AZ! -- count against the port quota for a tenant. So, in a practical sense, what this means is that for even a small AZ with 16 compute workers, even though a tenant's default network, subnet, and router quota is 10, the tenant actually won't be able to create more than a couple networks and floating IP addresses, since the port quota would be exhausted almost immediately.

Jay Pipes (jaypipes)
description: updated
description: updated
Revision history for this message
Mark McClain (markmcclain) wrote :

Compute worker? Are you referring to service agents such at DHCP?

Changed in neutron:
status: New → Incomplete
Revision history for this message
Jay Pipes (jaypipes) wrote :

Yes, DHCP agents running on compute workers.

tags: added: neutron-core quotas
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Revision history for this message
Édouard Thuleau (ethuleau) wrote :

I think this subject should be address.
I reopened the bug.

Changed in neutron:
status: Expired → New
Revision history for this message
Mark McClain (markmcclain) wrote :

This is something we should at work to address. I'm keeping the bug open for now, but a blueprint feels like a better vehicle to track this.

Changed in neutron:
importance: Undecided → Low
status: New → Triaged
importance: Low → Wishlist
tags: added: l3-ipam-dhcp
Changed in neutron:
milestone: none → icehouse-3
Revision history for this message
Jaume Devesa (devvesa) wrote :

I've test this and I've seen that auto-created ports belong always to a 'network:*' owner

mysql> select id, device_owner, status from ports;
+--------------------------------------+--------------------------+--------+
| id | device_owner | status |
+--------------------------------------+--------------------------+--------+
| 078f707b-791b-4001-bbf0-b752f62f45aa | | DOWN |
| 5b94981f-8c53-48a8-92d9-f0a80778bb15 | network:dhcp | ACTIVE |
| 8840c827-48d1-4956-a166-3fb3595c1f24 | compute:nova | ACTIVE |
| 97723714-c35a-4b23-aa10-55052ceda223 | network:router_gateway | ACTIVE |
| b5969367-1462-4ad2-8a61-e24003f34411 | network:router_interface | ACTIVE |
| dd017c8d-b740-4457-a2e2-548ee381d2bc | | DOWN |
+--------------------------------------+--------------------------+--------+

* compute:nova is a port created by deploying instance
* the empty ones are created manually by 'neutron port-create'

Maybe filtering by 'device_owner' field in quota_db would be enough to solve this issue.

Jaume Devesa (devvesa)
Changed in neutron:
assignee: nobody → Jaume Devesa (devvesa)
Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

That would be an easy way of temporarily sorting the issue.

I say "temporarily" because the fact that auto-created ports have a device_owner starting with "network" is the current situation and may change in the future.
Also, it is an attribute which is modifiable, even if only with admin credentials.

I am not sure if we want to go down this route.
I would choose it if this bug has a non-negligible severity, which is probably not the case as its priority is currently set to "Wishlist"

Revision history for this message
Jaume Devesa (devvesa) wrote :

Ok so...

I don't want to be late at the icehouse~3 milestone. So I will wait a couple of days to see if any other person finds a better solution.

If not, I will propose a patch with this approach with a proper test. Once this situation will change (no device_owner starting with "network") we will see it.

Agree?

Thierry Carrez (ttx)
Changed in neutron:
milestone: icehouse-3 → icehouse-rc1
Changed in neutron:
milestone: icehouse-rc1 → none
tags: added: icehouse-rc-potential
tags: added: icehouse-backport-potential
removed: icehouse-rc-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/99679

Changed in neutron:
status: Triaged → In Progress
Kyle Mestery (mestery)
Changed in neutron:
milestone: none → juno-2
Revision history for this message
Jaume Devesa (devvesa) wrote :

It seems that code reviewers are not convinced about this solution... and me neither now. (https://review.openstack.org/#/c/99679/6/neutron/quota.py) So I would like to open a discussion again here about how to approach this issue from another way.

Any crazy idea?

Revision history for this message
Rossella Sblendido (rossella-o) wrote :

Hello Jaume. As I commented on the review, I think a possible solution would be to expose in neutron server config file which type of ports are excluded from the quota count.

Something like:

port_type_excluded_from_quota_count = network:dhcp, network:floatingip

In the example dhcp and floating ip ports won't count against the port quota.

This can go further and could be defined for each tenant. But this would require much more work, since data will have to be stored in the DB and API calls need to be provided.
Anyway this discussion fits more in a blueprint then a in a bug in my opinion.

Revision history for this message
Jaume Devesa (devvesa) wrote :

Hello Rosella,

thanks for the response! I forgot to respond you in the review yesterday after my last comment. I'm agree with you that there is much more work because the excluded filter does not exist in any of the _get_(entity)_count() method there, and I think in terms of coherency the filters should be developed in each one of these methods. But even though I implement this solution, it will be the same kind of solution. I mean that the *device_owner* will still be editable and that won't guarantee the port_count coherency.

Keep thinking about it...

Kyle Mestery (mestery)
Changed in neutron:
milestone: juno-2 → none
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Salvatore Orlando (<email address hidden>) on branch: master
Review: https://review.openstack.org/99679
Reason: This patch has been inactive long enough that I think it's safe to abandon.
The author can resurrect it if needed.

Alan Pevec (apevec)
tags: removed: icehouse-backport-potential
Changed in neutron:
status: In Progress → Incomplete
assignee: Jaume Devesa (devvesa) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.