[openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

Sean Dague sean at dague.net
Tue Jun 2 16:22:16 UTC 2015


Nova has a very large API, and during the last release cycle a lot of
work was done to move all the API checking properly into policy, and not
do admin context checks at the database level. The result is a very
large policy file -
https://github.com/openstack/nova/blob/master/etc/nova/policy.json

This provides a couple of challenges. One of which is in recent defcore
discussions some deployers have been arguing that the existence of
policy files means that anything you can do with policy.json is valid
and shouldn't impact trademark usage, because the knobs were given. Nova
specifically states this is not ok -
https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst#existed-nova-api-being-restricted
however, we'd like to go a step further here.

What we'd really like is sane defaults for policy that come from code,
not from etc files. So that a Nova deploy with an empty policy.json is
completely valid, and does a reasonable thing.

Policy.json would then be just a set of overrides for existing policy.
That would make it a lot more clear what was changed from the existing
policy.

We'd also really like the policy system to be able to WARN when the
server starts if the policy was changed in some way that could
negatively impact compatibility of the system, i.e. if functions that we
felt were essential were turned off. Because the default policy is in
code, we could have a view of the old and new world and actually warn
the Operator that they did a weird thing.

Lastly, we'd actually really like to redo our policy to look more like
resource urls instead of extension names, as this should be a lot more
sensible to the administrators, and hopefully make it easier to think
about policy. Which I think means an aliasing facility in oslo.policy to
allow a graceful transition for users. (This may exist, I don't know).

I'm happy to write specs here, but mostly wanted to have the discussion
on the list first to ensure we're all generally good with this direction.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list