[openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
john at johngarbutt.com
Wed Jun 3 09:33:57 UTC 2015
On 2 June 2015 at 17:22, Sean Dague <sean at dague.net> wrote:
> 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 -
In summary, we need to make it easier for the deployer configuring the
policy to "to the right thing".
The plan to remove the ability to turn off API "extensions", so we get
the Nova API back to a single official (microversioned) API, will make
it more important that its easy to "maintain" policy tweaks.
> 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 -
> 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
> 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).
+1 to all that.
One more thing to help those maintaining a policy that has several
levels of "admin" (frankly the most acceptable use of policy tweaks,
and something we might want to encode into our defaults at some point
if clear patterns emerge).
I think we need more hierarchy in the policy. For example, if you want
to disable all floating ip actions, it would be nice if that was a
single policy change. Basically having all floating ip actions inherit
from the top level policy (i.e. the actions default to the top level
policy, and have overrides when required). As we add extra API
actions, or extra more granular policy items, it should default in a
way thats easy to understand across an upgrade.
> 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.
Thanks for the awesome summary here.
I have added this to the list of post summit actions I am (still!)
compiling, in the section where we need folks to step on an own stuff:
More information about the OpenStack-dev