Comment 2 for bug 1890432

We've done some evaluation on neutron logs, neutron-server-2.log is the most relevant.

We can see the following stacktrace: https://pastebin.canonical.com/p/SMKvPbnnmZ/

The original request for subnet creation is: req-32f521c9-9634-4483-9e50-944033b515ee
Which relates to subnet: 432de530-47b4-4587-b623-ed5b4cbe0c39

However, the stacktrace cites another subnet: 40868773-ded4-4047-9c2e-a0a41cfdb143

Which has been deleted just before the stacktrace:
2020-08-04 14:23:43.121 1528233 DEBUG neutron.db.db_base_plugin_v2 [req-b5c62ce8-2c3b-4893-a103-6cdb8662f5d3 848f111e240b46d682e99836147297b6 2b99334dcd4c487ca49edeb5149c2699 - 7a9fab9568114905b8c864caaa6468e1 7a9fab9568114905b8c864caaa6468e1] Deleting subnet 40868773-ded4-4047-9c2e-a0a41cfdb143 delete_subnet /usr/lib/python3/dist-packages/neutron/db/db_base_plugin_v2.py:1042

Here is the stack with the delete just before:
https://pastebin.canonical.com/p/yDQsxb8ktf/

Looking at the driver code, I can see: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L2096

Which, at one subnet creation, grabs all the subnets for the same network and checks one by one for metadata port. However, if one subnet has been set for deletion just before, that can cause errors from concurrency.

The commit for that line is pretty old, it dates from original repo: openstack/networking-ovn.
Here: https://github.com/openstack/networking-ovn/commit/ad1fea3e7ba837d521c924b285294d7cf2efcefb

Would that be possible to tweak "update_metadata_port" method to only look for metadata port for the subnet that has been created? Otherwise, we need to assume that not all the other subnets are available for edit at the moment of the request.

In my view, editing all subnets at once only makes sense if we had a config change to enable DHCP or metadata services and we need to set it for them all. That can be done at neutron-server restart instead.