prevent auto-deletion of ports when external net is deleted

Bug #1044331 reported by dan wendlandt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
dan wendlandt

Bug Description

this change https://review.openstack.org/#/c/11996/6/quantum/db/db_base_plugin_v2.py means that ports with owner 'network:*' will be ignored for the network delete check. we may want to limit that to dhcp and router interface ports. Needs more discussion

dan wendlandt (danwent)
Changed in quantum:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → dan wendlandt (danwent)
milestone: none → folsom-rc1
dan wendlandt (danwent)
summary: - revisit which ports will be auto-deleted on network delete
+ prevent auto-deletion of ports when external net is deleted
Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

Floating IPs should not be removed automatically when the external network is deleted IMHO.
On the other hand, I am not very keen of adding another conditional test to plugin logic, as this will introduce complexity.

Which is the rational beyond assigning DEVICE_OWNER_FLOATINGIP as device_owner for floating ports? Can they be owned by the tenant that creates the floating IP?

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

Device owner isn't really a tenant_id, it is a string of the form 'compute:server' or 'network:dhcp'. Its really more about helping people understand the "type" of port, or who is "consuming" the port.

My thinking is that an admin should have to make sure all floating ips + gateway services should be deallocated from an 'external network' before they can delete that network.

I actually think this change is essentially a few lines. I will propose a fix, then we can discuss.

Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

I've realized where I was wrong after we discussed the changes in the L3 policy patch this morning.

It could be easily done di changing the code referenced in the bug report for not regarding floating ip ports as "service ports".
This would a quick fix, although there are definitely better fixes.

One other thing to consider i where we want to keep allow_post:True and allow_put:True on the device owner attribute, or make it read-only.

If the L3 agent calls in the Quantum API and needs to write this attribute, we could make the field admin_only (policy already supports this out of the box)

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/12676

Changed in quantum:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/12676
Committed: http://github.com/openstack/quantum/commit/99f8912283332f76bc20d8094e6dd1187932adc1
Submitter: Jenkins
Branch: master

commit 99f8912283332f76bc20d8094e6dd1187932adc1
Author: Dan Wendlandt <email address hidden>
Date: Sun Sep 9 07:53:37 2012 -0700

    Prevent floating-ip and ex-gateway ports should prevent net deletion

    bug 1044331

    Old behavior meant that any port with device owner starting with
    "network:" would be auto-deleted when a network was deleted. We don't
    want that behavior for floating IPs or external network gateways.
    This provides a model where we explicitly list the set of owners that
    should be auto-deleted.

    - Also clean up NetworkInUse message to no longer mention 'attachment',
    since that is API v1 terminology.

    Change-Id: Icb727ae86d490456ec1ebc55cec1bf98ae6490c9

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.