Open Stack

Ideally I would like to see it in the form of least specific to most
specific. But more importantly in a way that there is no additional
delimiters between the service type and the resource. Finally, I do not
like the change of plurality depending on action type.

I propose we consider

*<service-type>:<resource>:<action>[:<subaction>]*

Example for keystone (note, action names below are strictly examples I am
fine with whatever form those actions take):
*identity:projects:create*
*identity:projects:delete*
*identity:projects:list*
*identity:projects:get*

It keeps things simple and consistent when you're looking through overrides
/ defaults.
--Morgan

On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad at gmail.com> wrote:

> Bumping this thread again and proposing two conventions based on the
> discussion here. I propose we decide on one of the two following
> conventions:
>
> *<service-type>:<action>:<resource>*
>
> or
>
> *<service-type>:<action>_<resource>*
>
> Where <service-type> is the corresponding service type of the project [0],
> and <action> is either create, get, list, update, or delete. I think
> decoupling the method from the policy name should aid in consistency,
> regardless of the underlying implementation. The HTTP method specifics can
> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>
> I think the plurality of the resource should default to what makes sense
> for the operation being carried out (e.g., list:foobars, create:foobar).
>
> I don't mind the first one because it's clear about what the delimiter is
> and it doesn't look weird when projects have something like:
>
> <service-type>:<action>:<subaction>:<resource>
>
> If folks are ok with this, I can start working on some documentation that
> explains the motivation for this. Afterward, we can figure out how we want
> to track this work.
>
> What color do you want the shed to be?
>
> [0] https://service-types.openstack.org/service-types.json
> [1]
> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
>
> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad <lbragstad at gmail.com>
> wrote:
>
>>
>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <gmann at ghanshyammann.com>
>> wrote:
>>
>>>  ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
>>> john at johngarbutt.com> wrote ----
>>>  > tl;dr+1 consistent names
>>>  > I would make the names mirror the API... because the Operator setting
>>> them knows the API, not the codeIgnore the crazy names in Nova, I certainly
>>> hate them
>>>
>>> Big +1 on consistent naming  which will help operator as well as
>>> developer to maintain those.
>>>
>>>  >
>>>  > Lance Bragstad <lbragstad at gmail.com> wrote:
>>>  > > I'm curious if anyone has context on the "os-" part of the format?
>>>  >
>>>  > My memory of the Nova policy mess...* Nova's policy rules
>>> traditionally followed the patterns of the code
>>>  > ** Yes, horrible, but it happened.* The code used to have the
>>> OpenStack API and the EC2 API, hence the "os"* API used to expand with
>>> extensions, so the policy name is often based on extensions** note most of
>>> the extension code has now gone, including lots of related policies* Policy
>>> in code was focused on getting us to a place where we could rename policy**
>>> Whoop whoop by the way, it feels like we are really close to something
>>> sensible now!
>>>  > Lance Bragstad <lbragstad at gmail.com> wrote:
>>>  > Thoughts on using create, list, update, and delete as opposed to
>>> post, get, put, patch, and delete in the naming convention?
>>>  > I could go either way as I think about "list servers" in the API.But
>>> my preference is for the URL stub and POST, GET, etc.
>>>  >  On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad <lbragstad at gmail.com>
>>> wrote:If we consider dropping "os", should we entertain dropping "api",
>>> too? Do we have a good reason to keep "api"?I wouldn't be opposed to simple
>>> service types (e.g "compute" or "loadbalancer").
>>>  > +1The API is known as "compute" in api-ref, so the policy should be
>>> for "compute", etc.
>>>
>>> Agree on mapping the policy name with api-ref as much as possible. Other
>>> than policy name having 'os-', we have 'os-' in resource name also in nova
>>> API url like /os-agents, /os-aggregates etc (almost every resource except
>>> servers , flavors).  As we cannot get rid of those from API url, we need to
>>> keep the same in policy naming too? or we can have policy name like
>>> compute:agents:create/post but that mismatch from api-ref where agents
>>> resource url is os-agents.
>>>
>>
>> Good question. I think this depends on how the service does policy
>> enforcement.
>>
>> I know we did something like this in keystone, which required policy
>> names and method names to be the same:
>>
>>   "identity:list_users": "..."
>>
>> Because the initial implementation of policy enforcement used a decorator
>> like this:
>>
>>   from keystone import controller
>>
>>   @controller.protected
>>   def list_users(self):
>>       ...
>>
>> Having the policy name the same as the method name made it easier for the
>> decorator implementation to resolve the policy needed to protect the API
>> because it just looked at the name of the wrapped method. The advantage was
>> that it was easy to implement new APIs because you only needed to add a
>> policy, implement the method, and make sure you decorate the implementation.
>>
>> While this worked, we are moving away from it entirely. The decorator
>> implementation was ridiculously complicated. Only a handful of keystone
>> developers understood it. With the addition of system-scope, it would have
>> only become more convoluted. It also enables a much more copy-paste pattern
>> (e.g., so long as I wrap my method with this decorator implementation,
>> things should work right?). Instead, we're calling enforcement within the
>> controller implementation to ensure things are easier to understand. It
>> requires developers to be cognizant of how different token types affect the
>> resources within an API. That said, coupling the policy name to the method
>> name is no longer a requirement for keystone.
>>
>> Hopefully, that helps explain why we needed them to match.
>>
>>
>>>
>>> Also we have action API (i know from nova not sure from other services)
>>> like POST /servers/{server_id}/action {addSecurityGroup} and their current
>>> policy name is all inconsistent.  few have policy name including their
>>> resource name like "os_compute_api:os-flavor-access:add_tenant_access", few
>>> has 'action' in policy name like
>>> "os_compute_api:os-admin-actions:reset_state" and few has direct action
>>> name like "os_compute_api:os-console-output"
>>>
>>
>> Since the actions API relies on the request body and uses a single HTTP
>> method, does it make sense to have the HTTP method in the policy name? It
>> feels redundant, and we might be able to establish a convention that's more
>> meaningful for things like action APIs. It looks like cinder has a similar
>> pattern [0].
>>
>> [0]
>> https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-actions-volumes-action
>>
>>
>>>
>>> May be we can make them consistent with
>>> <service-type>:<resource>:<action_with_snake_case> or any better opinion.
>>>
>>>  > From: Lance Bragstad <lbragstad at gmail.com>> The topic of having
>>> consistent policy names has popped up a few times this week.
>>>  >
>>>  > I would love to have this nailed down before we go through all the
>>> policy rules again. In my head I hope in Nova we can go through each policy
>>> rule and do the following:
>>>  > * move to new consistent policy name, deprecate existing name*
>>> hardcode scope check to project, system or user** (user, yes... keypairs,
>>> yuck, but its how they work)** deprecate in rule scope checks, which are
>>> largely bogus in Nova anyway* make read/write/admin distinction** therefore
>>> adding the "noop" role, amount other things
>>>
>>> + policy granularity.
>>>
>>> It is good idea to make the policy improvement all together and for all
>>> rules as you mentioned. But my worries is how much load it will be on
>>> operator side to migrate all policy rules at same time? What will be the
>>> deprecation period etc which i think we can discuss on proposed spec -
>>> https://review.openstack.org/#/c/547850
>>
>>
>> Yeah, that's another valid concern. I know at least one operator has
>> weighed in already. I'm curious if operators have specific input here.
>>
>> It ultimately depends on if they override existing policies or not. If a
>> deployment doesn't have any overrides, it should be a relatively simple
>> change for operators to consume.
>>
>>
>>>
>>>
>>> -gmann
>>>
>>>  > 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
>>>  >
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180928/8a6edc76/attachment.html>