Segment-aware scheduling fails for non-admin users
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Unassigned | ||
Wallaby |
In Progress
|
Undecided
|
Unassigned | ||
Xena |
In Progress
|
Undecided
|
Unassigned | ||
Yoga |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
This is a follow-up to https:/
Having deployed the Nova scheduler configuration for routed provider networks as follows (Xena deployment @ 7df9379d6661233
[scheduler]
query_placement
When the above configuration is enabled, creation of new instances for admin users works correctly, but for non-admin users against the same networks results in the following error:
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
285768 ERROR oslo_messaging.
It appears that the subnet dictionaries are returned empty from the Neutron client library in this case, causing the KeyError.
As far as I can see, a matching command line request for 'openstack subnet show X' as the same requesting user correctly includes the 'segment_id', but I don't know how similar this code path and the permissions handling is.
I'd be happy to test out other requests or obtain additional logs if useful.
tags: | added: neutron scheduler |
Thanks for the report! I was able to reproduce the problem on master as well.
The nova code at [1] creates the neutron client based on the request context. If the request is coming from an admin user then the neutron client will be an admin client too. In this case neutron returns the segment_id field in the GET /subnets response.
However if the requester is a non-admin then nova will query neutron with a non-admin client too. And base on my quick testing in a devstack from master neutron indeed does not return the segment_id field for a non-admin user.
So this is valid bug.
The easiest solution would be to change [2] to always create and neutron admin client with:
get_ client( context, admin=True)
I'm setting this to Triaged. Feel free to assign this to yourself and propose a patch fixing this.
[1] https:/ /github. com/openstack/ nova/blob/ a1f006d799d2294 234d381395a9ae9 c22a2d80b9/ nova/network/ neutron. py#L3858- L3867 /github. com/openstack/ nova/blob/ a1f006d799d2294 234d381395a9ae9 c22a2d80b9/ nova/network/ neutron. py#L3858
[2] https:/