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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
