[openstack-dev] [nova] Policy check for network:attach_external_network

Matt Riedemann mriedem at linux.vnet.ibm.com
Wed Jun 8 22:28:02 UTC 2016

On 6/8/2016 4:27 PM, Ryan Rossiter wrote:
> Taking a look at [1], I got curious as to why all of the old network policies were deleted except for network:attach_external_network. With the help of mriedem, it turns out that policy is checked indirectly on the compute node, in allocate_for_instance(). mriedem pointed out that this policy doesn’t work very well from an end-user perspective, because if you have an existing instance and want to now attach it to an external network, it’ll reschedule it, and if you don’t have permission to attach to an external network, it’ll bounce around the scheduler until the user receives the infamous “No Valid Host”.
> My main question is: how do we want to handle this? I’m thinking because Neutron has all of the info as to whether or not the network we’re creating a port on is external, we could just let Neutron handle all of the policy work. That way eventually the policy can just leave nova’s policy.json. But that’ll take a while.
> A temporary alternative is we move that policy check to the API. That way we can accurately deny the user instead of plumbing things down into the compute for them to be denied there. I did a scavenger hunt and found that the policy check was added because of [2], which, in the end, is just a permissions thing. So that could get added to the API checks when 1) creating an instance and 2) attaching an existing instance to another network. Are there any other places this API check would be needed?
> [1]: https://review.openstack.org/#/c/320751/
> [2]: https://bugs.launchpad.net/nova/+bug/1352102
> -----
> Thanks,
> Ryan Rossiter (rlrossit)
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

When I looked at this (briefly) the check is done in 
allocate_for_instance which is called when creating a server and when 
attaching interfaces to an existing server. The create is a cast and 
gets into the NoValidHost failure. The attach is a call and the user 
would at least get a 400 back.

If we moved that check to the validate_networks() method it would get 
validated in the API when creating the server, which is good for 
avoiding the NoValidHost case. However, attach_interfaces doesn't call 
validate_networks and I'm not really sure why, it seems we'd want the 
same network/port/quota checking in that case. Although 
validate_networks also returns the number of instances you can create 
for the multi-create scenario - which is really just creating servers, 
not attaching interfaces.

So we'd either have to call validate_networks when attaching interfaces, 
or do the policy check in the attach_interfaces flow - which would mean 
getting the available networks up front, which also sucks.

I guess we could just do that check in both validate_networks (server 
create API) and allocate_for_instance (attach interfaces API). The gross 
thing about leaving it in allocate_for_instance is you have a policy 
check in the compute node still.



Matt Riedemann

More information about the OpenStack-dev mailing list