Comment 2 for bug 1591766

As discussed with Kevin in IRC, we still have a potential race in nova because nova is checking for available networks when none are provided in the boot request, it gets the list by checking:

1. private tenant-owned networks
2. public shared=True networks

If that's empty, and auto was requested, nova calls the auto-allocated-topology API.

But let's say there are 3 concurrent server create requests for the tenant.

1. first gets in and creates the 'real' network
2. second gets in and calls auto-allocated-topology because it didn't see the network from #1 yet, but neutron sees the network from #1 and logs that error and returns the network from #1.
3. the third request is building the list of available networks, and sees the first two networks created already - this will result in an error on the nova side:

https://review.openstack.org/#/c/316275/12/nova/network/neutronv2/api.py@574

Because of the network ambiguous error.

If there was some kind of way to filter the networks up front on the nova side to avoid getting networks 1 and 2 from the scenario above, like if the networks status was ALLOCATING or something, then maybe nova could filter the bad one out up front.

Realistically this is an edge case, and it would be a one time failure for a tenant that doesn't already have a network and is doing multiple boot requests on that first try - but for a new user it would be a pretty crappy experience having your first server create request fail.