The reason is
- LinuxOVSInterfaceDriver implements unplug as nop.
- It creates gw-xxx and register the port to Quantum at the time first instance is created
- When deleting network, the gw-xxx reamins. So network deletion request to quantum fails
due to the interface gw-xxx is attached and busy.

The fix would be
- implement unplug and call unattach and delete the port request to quantum
- stop dnsmasq daemon

Thanks for reporting this bugs, and for proposing a strategy for fixing it.

I'm not really up-to-date on the Quantum-nova integration, but I was wondering why we would need to stop dnsmasq. This might make sense with the VLAN manager, altough I think there is already code in place for destroying resources on the network node, including the dnsmasq instance, when a network is delete.

However, in FlatDHCP mode, if I'm not wrong the same dnsmasq instance is used for all networks (several IP addresses are configured on the bridge).

Thanks for the bug report! Its great to also report such issues in the Quantum project (or send email to the netstack list) as sometimes quantum developers won't see a bug that is just filed under nova. Thankfully Salvatore noticed this one.

This bug is specific to using DHCP / L3 NAT gateways.

The fact that LinuxOVSInterfaceDriver doesn't do anything on unplug is not actually the problem (though its something we should clean up anyway, as there will be stale linux devices lying around...).

I believe the real issue is that QuantumManager needs to clean up the "gateway" port on a Quantum network before attempting to delete it, otherwise Quantum refuses to to delete the network with a NetworkInUse error. This should be a QuantumManager fix.