The routine for deleting a subnet checks whether it's ok to remove a subnet in the following way:
1) Query IP allocations on the subnet for ports that can be automatically deleted
2) Remove those allocations
3) Check again subnet allocations. If there is any other allocation this means that there are some IPs that cannot be automatically deleted
4) Raise a conflict exception
In the case of SLAAC or DHCP_STATELESS IPv6 subnets, every IP address can be automatically deleted - and that's where the problem lies.
Indeed the query performed at step #3 [1] and [2] for ML2 plugin, might cause a failure during subnet deletion if:
- The transaction isolation level is set to READ COMMITTED
- The subnet address mode is either SLAAC or DHCP STATELESS
- A port is created concurrently with the delete subnet procedure and an IP address is assigned to it.
These circumstances are quite unlikely to occur, but far from impossible. They are indeed seen in gate tests [3].
It is advisable to provide a fix for this issue. To this aim it is probably worth noting that the check #3 is rather pointless for subnets with automatic address mode.
[1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/db_base_plugin_v2.py#n1240
[2] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/plugin.py#n810
[3] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVW5hYmxlIHRvIGNvbXBsZXRlIG9wZXJhdGlvbiBvbiBzdWJuZXRcIiBBTkQgbWVzc2FnZTpcIk9uZSBvciBtb3JlIHBvcnRzIGhhdmUgYW4gSVAgYWxsb2NhdGlvbiBmcm9tIHRoaXMgc3VibmV0XCIgQU5EIHRhZ3M6Y29uc29sZSBBTkQgYnVpbGRfc3RhdHVzOkZBSUxVUkUgQU5EIGJ1aWxkX25hbWU6XCJjaGVjay1ncmVuYWRlLWRzdm0tbmV1dHJvblwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDIyMDQ1MDA1OTE3LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9
Fix proposed to branch: master
Review: https:/