Open Stack

Hello Sean!

+1 on defaults, resource-url style entries, hierarchy

But, in the interest of staying "declarative", I am not comfortable with having default policies in code.
I would rather have a default nova policy.json file in the nova code base and if no policy.json is supplied, have the nova code
copy over this default to the /etc location, and log the same.

Admin related access changes are easier to determine in the custom policy.json, but with the introduction of roles, which could act as aliases,
Policy.json can easily be morphed to become more promiscuous or ultra stringent. Harder to determine and alert.

Also thinking that in the context of dynamic policies and being able via API to introduce policy changes that take into consideration new roles
Introduced, can see policy changes being saved in the database, changes being logged, but also for ease of use/review, nice to write out to a policy.json
file, one per project.

Thanks
Malini

-----Original Message-----
From: John Garbutt [mailto:john at johngarbutt.com] 
Sent: Wednesday, June 03, 2015 2:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

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 - 
> https://github.com/openstack/nova/blob/master/etc/nova/policy.json

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 - 
> 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).

+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:
https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items

Thanks,
John

__________________________________________________________________________
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