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-requ...@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.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
