Unable to delete a router port

Bug #1039947 reported by Gary Kotton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
dan wendlandt

Bug Description

gkotton@gkotton-ubuntu12:~/devstack$ quantum port-delete 079a8701-57d8-4c84-8f14-5df8a60744a3
(IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`ovs_quantum`.`floatingips`, CONSTRAINT `floatingips_ibfk_1` FOREIGN KEY (`floating_port_id`) REFERENCES `ports` (`id`))') 'DELETE FROM ports WHERE ports.id = {'message': u"(IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`ovs_quantum`.`floatingips`, CONSTRAINT `floatingips_ibfk_1` FOREIGN KEY (`floating_port_id`) REFERENCES `ports` (`id`))') 'DELETE FROM ports WHERE ports.id = %s' ('079a8701-57d8-4c84-8f14-5df8a60744a3',)"}' ('079a8701-57d8-4c84-8f14-5df8a60744a3',)

Configuration:
gkotton@gkotton-ubuntu12:~/devstack$ quantum port-list
+----------------+-------------------------------------------------------------------------------+--------------------------+---------------------------------------------------------------------------------+--------------------------------------+-------------------+------------+--------------------------------------+--------+----------------------------------+
| admin_state_up | device_id | device_owner | fixed_ips | id | mac_address | name | network_id | status | tenant_id |
+----------------+-------------------------------------------------------------------------------+--------------------------+---------------------------------------------------------------------------------+--------------------------------------+-------------------+------------+--------------------------------------+--------+----------------------------------+
| True | dhcp8f0b91d2-f2d2-5027-af20-58e892a7e033-641afa51-0d69-43a9-b5f2-82f4eaac081e | network:dhcp | {"subnet_id": "08780e97-19cb-41b7-aa15-da7e3957e8a8", "ip_address": "10.0.0.2"} | 05ec17b2-4246-44fe-b4ba-76cd959a6df5 | fa:16:3e:ee:e7:b6 | DHCP Agent | 641afa51-0d69-43a9-b5f2-82f4eaac081e | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | 7b760a38-4ba7-487e-a51b-7fdfb4f94d90 | network:floatingip | {"subnet_id": "8ad699f0-ee2a-4b54-b4a9-0d932a62063c", "ip_address": "40.0.0.4"} | 079a8701-57d8-4c84-8f14-5df8a60744a3 | fa:16:3e:31:4e:57 | | 007716aa-b2c3-49a6-81b0-d8edaa1cace1 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | 1b4914bf-99bf-4b4e-88c3-b9fec93beb2c | network:router_interface | {"subnet_id": "038bf339-d6a5-47af-9bc8-65696581d8f7", "ip_address": "92.0.0.1"} | 38889b93-fba7-42e8-a7d1-c8d20b68eb4b | fa:16:3e:40:18:31 | | c865dc48-91cc-4fd0-8a18-385206c709c7 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | 1b4914bf-99bf-4b4e-88c3-b9fec93beb2c | network:router_interface | {"subnet_id": "21c49cab-9640-456e-9436-1cb3787a5c3b", "ip_address": "91.0.0.1"} | 7e3c2b8f-73a7-43bb-826d-d86dd1c8d049 | fa:16:3e:88:96:77 | | 11b3cb9b-c18f-4f36-bdfe-3b1253ebc465 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | e7aa1ba9-0bcd-4411-b3ea-9252602d8c7e | compute:nova | {"subnet_id": "038bf339-d6a5-47af-9bc8-65696581d8f7", "ip_address": "92.0.0.2"} | b76d7793-f3e0-406b-a7cd-b6243acb0905 | fa:16:3e:f0:48:e3 | | c865dc48-91cc-4fd0-8a18-385206c709c7 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | b77f39a4-831a-4e1f-be5a-11c288d1d4af | compute:nova | {"subnet_id": "21c49cab-9640-456e-9436-1cb3787a5c3b", "ip_address": "91.0.0.2"} | c50cdb42-14b6-4b6c-a28f-865ed206613e | fa:16:3e:5d:41:d6 | | 11b3cb9b-c18f-4f36-bdfe-3b1253ebc465 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
| True | d7ecdd77-d120-4b28-8d93-6745abadf914 | network:floatingip | {"subnet_id": "8ad699f0-ee2a-4b54-b4a9-0d932a62063c", "ip_address": "40.0.0.3"} | c9472eb3-d15c-4929-8d7a-d8e232996a52 | fa:16:3e:a3:62:d0 | | 007716aa-b2c3-49a6-81b0-d8edaa1cace1 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
+----------------+-------------------------------------------------------------------------------+--------------------------+---------------------------------------------------------------------------------+--------------------------------------+-------------------+------------+--------------------------------------+--------+----------------------------------+
gkotton@gkotton-ubuntu12:~/devstack$ quantum router-list
+----------------+-----------------------+--------------------------------------+---------+--------+----------------------------------+
| admin_state_up | external_gateway_info | id | name | status | tenant_id |
+----------------+-----------------------+--------------------------------------+---------+--------+----------------------------------+
| True | | 1b4914bf-99bf-4b4e-88c3-b9fec93beb2c | router1 | ACTIVE | 237a056a6d28473ca1faba6ca6a846a9 |
+----------------+-----------------------+--------------------------------------+---------+--------+----------------------------------+
gkotton@gkotton-ubuntu12:~/devstack$

Gary Kotton (garyk)
Changed in quantum:
assignee: nobody → Gary Kotton (garyk)
milestone: none → folsom-rc1
importance: Undecided → Critical
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

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

Changed in quantum:
status: New → In Progress
Revision history for this message
dan wendlandt (danwent) wrote :

Hi Gary,

I mentioned this in the review, but those ports are not actually router ports, rather, they are internal ports that should be owned by the system, not by a tenant. Where did you get that port UUID? Was it returned in a list port operation? If so, where you an admin user? As I mentioned on the review, this port should only be deleted when the floating IP itself is deleted, so perhaps we should add a check to prevent people from deleting it in the API (I had thought that the port itself would be hidden, but it seems that is not the case).

Revision history for this message
dan wendlandt (danwent) wrote :

I see, you included the output already. I assume you ran this as the admin user? As I don't think an actual tenant would have seen this port, as we set the tenant-id to "".

My plan to handle this is to prevent the deletion of ports with owner "network:floatingip". Does that sound reasonable?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in quantum:
assignee: Gary Kotton (garyk) → dan wendlandt (danwent)
dan wendlandt (danwent)
Changed in quantum:
importance: Critical → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/11834
Committed: http://github.com/openstack/quantum/commit/8fb4e6efe8dcf1987d41917f71da8db345647321
Submitter: Jenkins
Branch: master

commit 8fb4e6efe8dcf1987d41917f71da8db345647321
Author: Dan Wendlandt <email address hidden>
Date: Fri Aug 31 04:29:12 2012 -0700

    prevent invalid deletion of ports using by L3 devices

    bug 1039947

    The bug noticed that an admin user could delete a port that stored
    the underlying IP allocation for a floating IP. This patch prevents
    the direction deletion of ports via the API for ports that are used as
    router interfaces, router gateways, of for floating IPs.

    Add a unit test to check such an invalid delete, and also updates
    unit tests to avoid them tripping over the new checks.

    Change-Id: Ief28e3181583428d55259275a7c21151a4a4fa9b

Changed in quantum:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in quantum:
milestone: folsom-rc1 → 2012.2
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.