Comment 1 for bug 1239637

This snippet of log is critical to understanding why we get an Integrity error on network delete:


2013-11-01 05:45:29.608 460 DEBUG neutron.plugins.ml2.plugin [-] Ports to auto-delete: [] delete_network /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:387
2013-11-01 05:45:29.610 460 DEBUG neutron.plugins.ml2.plugin [-] Subnets to auto-delete: [] delete_network /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:401
2013-11-01 05:45:29.627 460 DEBUG neutron.plugins.ml2.plugin [-] Deleting network record delete_network /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:411
2013-11-01 05:45:29.629 460 DEBUG neutron.db.db_base_plugin_v2 [-] Generated mac for network 3022a674-2f18-4120-abde-86192d239879 is fa:16:3e:14:92:66 _generate_mac /opt/stack/new/neutron/neutron/db/db_base_plugin_v2.py:302
2013-11-01 05:45:29.631 460 DEBUG neutron.plugins.ml2.plugin [-] Committing transaction delete_network /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:420

The trace about mac generation before committing the network delete is due to the dhcp port being created concurrently by the the dhcp agent. There are many ways in which this can be addressed, for instance, marking the network for deletion and ensuring that the dhcp does not create the port in the first place. However, since adding a new status to the network may be more convoluted and require a more thorough inspection of the code, it may be safer to just catch the integrity violation and try deleting the network again after the port gets re-read by the delete method.