Cascade router delete should also unlink ports

[adjohn]

When deleting a router, it fails if a port is linked to an interface. Cascade delete should probably unlink ports as well.

[gdecandia]

I know very little about the integration layer, but I saw this issue and wanted to write some notes.

Unlinking ports leaves them dangling on the peer device, so those probably need to be deleted too. Also:

• if the peer device is a router, it may have routes that point to the dangling port.
• if the peer device is a bridge, it may have mac-port mappings with the dangling port. So further cleanup is necessary, and if it is done automatically, it may leave the peer device in an incorrect state.

I assume @adjohn is referring to cascading delete of a Tenant's router. Therefore, we probably have good semantics for tear-down, that undo what was done during the setup of the router. However, also remember to un-assign any floating IPs that were NATed through the router - otherwise it may not be possible to un-assign them later. Also, the router has to give up its addresses on any subnets/networks that it was linked to (so that the addresses may be used by newly created routers).

[adjohn]

@gdecandia Sorry I wasn't clear, this was an unbind from the metadata-router port to the host/interface on the metadata-server host. This was done via the API, so this issue really belongs in MidoNet. I created a new issue /midokura/midonet/#565

Closing this issue since it is now moved to MidoNet project.

[gdecandia]

@adjohn

Sorry I wasn't clear, this was an unbind from the metadata-router port to the host/interface on the metadata-server host. This was done via the API, so this issue really belongs in MidoNet. I created a new issue /midokura/midonet/#565

But that was the point of my notes above: MidoNet alone does not have enough context to tear down routers set up by the integration layer. I think the tear-down of topology set up via Quantum should be done via Quantum commands.