Open Stack

and the 'nova-policy' command was introduced at the same time.... finally
found the right release notes:

ref: https://docs.openstack.org/releasenotes/nova/newton.html

The nova-policy command line is implemented as a tool to experience the
under-development feature policy discovery. User can input the credentials
infomation and the instance info, the tool will return a list of API which
can be allowed to invoke. There isn’t any contract for the interface of the
tool due to the feature still under-development.

and

The API policy defaults are now defined in code like configuration options.
Because of this, the sample policy.json file that is shipped with Nova is
empty and should only be necessary if you want to override the API policy
from the defaults in the code. To generate the policy file you can run:

oslopolicy-sample-generator --config-file=etc/nova/nova-policy-generator.conf


On Thu, Feb 23, 2017 at 3:17 PM, David Medberry <openstack at medberry.net>
wrote:

> Yep what Logan said. I'm pretty sure Sean Dague talked about this at the
> last Operator's mid-cycle.  The "blank" policy.json just means you get the
> default policies. You set a value to override the defaults.
>
> I don't see it in the Ocata relnotes but git indicates this is where it
> happened:
>
> https://github.com/openstack/nova/blob/stable/mitaka/etc/nova/policy.json
> https://github.com/openstack/nova/blob/stable/newton/etc/nova/policy.json
>
> again, no change in behavior...
>
> On Thu, Feb 23, 2017 at 3:06 PM, Logan V. <logan at protiumit.com> wrote:
>
>> I think this actually started in Newton. Yes it ships blank, however
>> there is still a default policy implemented as before with similar
>> defaults separating the admin and user roles. The default policy is
>> implemented in the nova code base
>> (https://github.com/openstack/nova/tree/stable/newton/nova/policies)
>> and overrides can be provided using policy.json (which also accepts
>> yaml despite what the file extension would lead you to believe). The
>> difference now is that the default policy is not enumerated in a
>> policy.json file by default. You can obtain the default policy by
>> running
>> oslopolicy-sample-generator --namespace nova
>>
>> There are also several other oslopolicy-* tools like
>> oslopolicy-list-redundant - can be used to list policies defined in
>> the policy.json which are redundant to the default policy
>> oslopolicy-checker -test access against a specific policy item
>> oslopolicy-policy-generator - dump a consolidated view of the policy
>> (ie defaults combined with overrides) for use with ie. horizon's
>> policy things. One thing I found with exporting this dump from nova
>> and using it in horizon is that you must define a policy called
>> "default" (usually set to "rule:admin_or_owner") because it is not
>> included in the dump and it seemed to cause some odd behavior in
>> horizon like the instances tab not showing up under the admin panel.
>>
>>
>> On Thu, Feb 23, 2017 at 1:52 PM, Edgar Magana <edgar.magana at workday.com>
>> wrote:
>> > Am I understanding correctly that in Ocata release, the policy.json
>> file for
>> > NOVA is blank?
>> >
>> > What does that mean for us (operators)? Everything will be open for
>> > everybody for the other way around?
>> >
>> >
>> >
>> > In any case, that sounds like an awful approach because know if we
>> upgrade
>> > we will need to be sure that we have a proper json file while in the
>> past we
>> > at least were starting from the default one.
>> >
>> >
>> >
>> > Edgar
>> >
>> >
>> >
>> > From: David Medberry <openstack at medberry.net>
>> > Date: Thursday, February 23, 2017 at 10:45 AM
>> > To: "openstack-operators at lists.openstack.org"
>> > <openstack-operators at lists.openstack.org>
>> > Subject: [Openstack-operators] Policy Updates
>> >
>> >
>> >
>> > Nova no longer ships with a fleshed-out skeleton of all policy.json. It
>> > ships blank.
>> >
>> >
>> >
>> > Discussion in here on how to help operators select specific settings to
>> > include in their policy.json via documentation.
>> >
>> >
>> >
>> > You (as an op) may want to review and comment on this. This model is
>> being
>> > proposed for all openstack projects (or at least MORE openstack
>> projects.)
>> >
>> >
>> >
>> > https://review.openstack.org/#/c/433010
>> >
>> >
>> > _______________________________________________
>> > OpenStack-operators mailing list
>> > OpenStack-operators at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170223/0462538a/attachment.html>