router_centralized_snat ports do not have project_id

Bug #1899502 reported by Arnaud Morin
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Low
Arnaud Morin

Bug Description

When adding a subnet to a distributed router, two interfaces are created:
- one for gateway (network:router_interface_distributed)
- one for snat / instance communication (network:router_centralized_snat)

The gw one is having a project_id:

$ openstack port show 4348275a-64bd-439f-be5c-9b3cf1a9160d
...
| project_id | 0819ce415874459dbd0d312cc15badee
...

While the snat one does not:

$ openstack port show 3258ebd9-2be4-4cf9-a110-c619906708ec
...
project_id |
...

Note that, both of them are visible by client:
$ openstack port list -c id -c device_owner
+--------------------------------------+--------------------------------------+----------------------------------+
| ID | device_owner | project_id |
+--------------------------------------+--------------------------------------+----------------------------------+
| 2f972668-e47c-41c1-90a8-17592f69ff3f | compute:nova | 0819ce415874459dbd0d312cc15badee |
| 3258ebd9-2be4-4cf9-a110-c619906708ec | network:router_centralized_snat | |
| 4348275a-64bd-439f-be5c-9b3cf1a9160d | network:router_interface_distributed | 0819ce415874459dbd0d312cc15badee |
| 5ccb4325-b687-4d8c-82d3-ebe5e9f163d0 | network:dhcp | 0819ce415874459dbd0d312cc15badee |
| 93ae1897-7af2-49f3-bfb0-af6050e75ea4 | network:floatingip | 0819ce415874459dbd0d312cc15badee |
+--------------------------------------+--------------------------------------+----------------------------------+

Code in charge of creating the GW port:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L761-L799

Code in charge of creating the SNAT port:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_dvr_db.py#L264-L278

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/757599

Changed in neutron:
assignee: nobody → Arnaud Morin (arnaud-morin)
Revision history for this message
LIU Yulong (dragon889) wrote :

IMO, it is a DVR "system internal use" port. It should not be visible to normal user to aviod unexpectedly removal.

Revision history for this message
Arnaud Morin (arnaud-morin) wrote :

But it is visible AFAICS.
But it's not possible to delete it with regular user rights:

Failed to delete port with name or ID '3258ebd9-2be4-4cf9-a110-c619906708ec': ConflictException: 409: Client Error for url: http://51.89.5.207:9696/v2.0/ports/3258ebd9-2be4-4cf9-a110-c619906708ec, Port 3258ebd9-2be4-4cf9-a110-c619906708ec cannot be deleted directly via the port API: has device owner network:router_centralized_snat.
1 of 1 ports failed to delete.

For me this is quite the same as a network:router_interface_distributed port, which is also not possible to delete.

I also dont think we should hide it from user, as the port is using an IP from the subnet pool, just like DHCP agent is doing. If we hide it, then is a chance the user think the IP is 'free'.

tags: added: l3-dvr-backlog
Changed in neutron:
importance: Undecided → Low
Changed in neutron:
status: New → Confirmed
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I agree with Arnaud in general. I am not familiar with DVR implementation, but if an IP address is consumed from a subnet defined by a user, a port which consumes the IP address from the subnet should be visible to the user.
It is what we already do for an interface (router port) of a non-DVR router. A neutron port corresponding to an interface of a non-DVR router is visible to a user but it cannot be deleted as long as a device owner is specified for the port.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/757599
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers