The change seems trivial enough, but when I grep the nova source tree (excluding tests) for "neutronv2.get_client" there are 42 matches. There are only 4 cases where admin=True in the call, which is in these nova.network.neutronv2.api methods:
allocate_for_instance // setting port bindings
_refresh_neutron_extensions_cache
_build_network_info_model
I'm not sure how to tell if the other calls to get the client should be using admin credentials or not, and if that somehow causes a race when working with networks depending on the context being used, but it seems fishy.
This might be a stab in the dark, but I'm wondering if this patch maybe has something to do with this bug and possibly bug 1265495:
https:/ /review. openstack. org/#/c/ 56174/
That merged around the time this bug was reported, but more interestingly when I backported that back to stable/havana in a topic branch:
https:/ /review. openstack. org/#/q/ status: open+project: openstack/ nova+branch: stable/ havana+ topic:backport- neutron- auth-fixes, n,z
I'm getting continual fails on the backport:
https:/ /review. openstack. org/#/c/ 70474/
Against bug 1265495.
The change seems trivial enough, but when I grep the nova source tree (excluding tests) for "neutronv2. get_client" there are 42 matches. There are only 4 cases where admin=True in the call, which is in these nova.network. neutronv2. api methods:
allocate_ for_instance // setting port bindings neutron_ extensions_ cache network_ info_model
_refresh_
_build_
I'm not sure how to tell if the other calls to get the client should be using admin credentials or not, and if that somehow causes a race when working with networks depending on the context being used, but it seems fishy.