Mailing List Archive

Re: [openstack-dev] [all] Consistent policy names
So +1

Tim

From: Lance Bragstad <lbragstad@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Wednesday, 12 September 2018 at 20:43
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, OpenStack Operators <openstack-operators@lists.openstack.org>
Subject: [openstack-dev] [all] Consistent policy names

The topic of having consistent policy names has popped up a few times this week. Ultimately, if we are to move forward with this, we'll need a convention. To help with that a little bit I started an etherpad [0] that includes links to policy references, basic conventions *within* that service, and some examples of each. I got through quite a few projects this morning, but there are still a couple left.

The idea is to look at what we do today and see what conventions we can come up with to move towards, which should also help us determine how much each convention is going to impact services (e.g. picking a convention that will cause 70% of services to rename policies).

Please have a look and we can discuss conventions in this thread. If we come to agreement, I'll start working on some documentation in oslo.policy so that it's somewhat official because starting to renaming policies.

[0] https://etherpad.openstack.org/p/consistent-policy-names
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
which maps to the "os-<service-type>-api:<resource>:<method>" format.

I selected it as it uses the service-type[1], references the API
resource, and then the method. So it maps well to the API reference[2]
for the service.

[0] https://docs.openstack.org/octavia/latest/configuration/policy.html
[1] https://service-types.openstack.org/
[2] https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer

Michael
On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
>
> So +1
>
>
>
> Tim
>
>
>
> From: Lance Bragstad <lbragstad@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
> Date: Wednesday, 12 September 2018 at 20:43
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, OpenStack Operators <openstack-operators@lists.openstack.org>
> Subject: [openstack-dev] [all] Consistent policy names
>
>
>
> The topic of having consistent policy names has popped up a few times this week. Ultimately, if we are to move forward with this, we'll need a convention. To help with that a little bit I started an etherpad [0] that includes links to policy references, basic conventions *within* that service, and some examples of each. I got through quite a few projects this morning, but there are still a couple left.
>
>
>
> The idea is to look at what we do today and see what conventions we can come up with to move towards, which should also help us determine how much each convention is going to impact services (e.g. picking a convention that will cause 70% of services to rename policies).
>
>
>
> Please have a look and we can discuss conventions in this thread. If we come to agreement, I'll start working on some documentation in oslo.policy so that it's somewhat official because starting to renaming policies.
>
>
>
> [0] https://etherpad.openstack.org/p/consistent-policy-names
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor@gmail.com> wrote:

> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
> which maps to the "os-<service-type>-api:<resource>:<method>" format.
>

Thanks for explaining the justification, Michael.

I'm curious if anyone has context on the "os-" part of the format? I've
seen that pattern in a couple different projects. Does anyone know about
its origin? Was it something we converted to our policy names because of
API names/paths?


>
> I selected it as it uses the service-type[1], references the API
> resource, and then the method. So it maps well to the API reference[2]
> for the service.
>
> [0] https://docs.openstack.org/octavia/latest/configuration/policy.html
> [1] https://service-types.openstack.org/
> [2]
> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
>
> Michael
> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
> >
> > So +1
> >
> >
> >
> > Tim
> >
> >
> >
> > From: Lance Bragstad <lbragstad@gmail.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> > Date: Wednesday, 12 September 2018 at 20:43
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, OpenStack Operators <
> openstack-operators@lists.openstack.org>
> > Subject: [openstack-dev] [all] Consistent policy names
> >
> >
> >
> > The topic of having consistent policy names has popped up a few times
> this week. Ultimately, if we are to move forward with this, we'll need a
> convention. To help with that a little bit I started an etherpad [0] that
> includes links to policy references, basic conventions *within* that
> service, and some examples of each. I got through quite a few projects this
> morning, but there are still a couple left.
> >
> >
> >
> > The idea is to look at what we do today and see what conventions we can
> come up with to move towards, which should also help us determine how much
> each convention is going to impact services (e.g. picking a convention that
> will cause 70% of services to rename policies).
> >
> >
> >
> > Please have a look and we can discuss conventions in this thread. If we
> come to agreement, I'll start working on some documentation in oslo.policy
> so that it's somewhat official because starting to renaming policies.
> >
> >
> >
> > [0] https://etherpad.openstack.org/p/consistent-policy-names
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
I don't know for sure, but I assume it is short for "OpenStack" and
prefixing OpenStack policies vs. third party plugin policies for
documentation purposes.

I am guilty of borrowing this from existing code examples[0].

[0] http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html

Michael
On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad <lbragstad@gmail.com> wrote:
>
>
>
> On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor@gmail.com> wrote:
>>
>> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
>> which maps to the "os-<service-type>-api:<resource>:<method>" format.
>
>
> Thanks for explaining the justification, Michael.
>
> I'm curious if anyone has context on the "os-" part of the format? I've seen that pattern in a couple different projects. Does anyone know about its origin? Was it something we converted to our policy names because of API names/paths?
>
>>
>>
>> I selected it as it uses the service-type[1], references the API
>> resource, and then the method. So it maps well to the API reference[2]
>> for the service.
>>
>> [0] https://docs.openstack.org/octavia/latest/configuration/policy.html
>> [1] https://service-types.openstack.org/
>> [2] https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
>>
>> Michael
>> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
>> >
>> > So +1
>> >
>> >
>> >
>> > Tim
>> >
>> >
>> >
>> > From: Lance Bragstad <lbragstad@gmail.com>
>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
>> > Date: Wednesday, 12 September 2018 at 20:43
>> > To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, OpenStack Operators <openstack-operators@lists.openstack.org>
>> > Subject: [openstack-dev] [all] Consistent policy names
>> >
>> >
>> >
>> > The topic of having consistent policy names has popped up a few times this week. Ultimately, if we are to move forward with this, we'll need a convention. To help with that a little bit I started an etherpad [0] that includes links to policy references, basic conventions *within* that service, and some examples of each. I got through quite a few projects this morning, but there are still a couple left.
>> >
>> >
>> >
>> > The idea is to look at what we do today and see what conventions we can come up with to move towards, which should also help us determine how much each convention is going to impact services (e.g. picking a convention that will cause 70% of services to rename policies).
>> >
>> >
>> >
>> > Please have a look and we can discuss conventions in this thread. If we come to agreement, I'll start working on some documentation in oslo.policy so that it's somewhat official because starting to renaming policies.
>> >
>> >
>> >
>> > [0] https://etherpad.openstack.org/p/consistent-policy-names
>> >
>> > _______________________________________________
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
Ok - yeah, I'm not sure what the history behind that is either...

I'm mainly curious if that's something we can/should keep or if we are
opposed to dropping 'os' and 'api' from the convention (e.g.
load-balancer:loadbalancer:post as opposed to
os_load-balancer_api:loadbalancer:post) and just sticking with the
service-type?

On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson <johnsomor@gmail.com> wrote:

> I don't know for sure, but I assume it is short for "OpenStack" and
> prefixing OpenStack policies vs. third party plugin policies for
> documentation purposes.
>
> I am guilty of borrowing this from existing code examples[0].
>
> [0]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html
>
> Michael
> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad <lbragstad@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor@gmail.com>
> wrote:
> >>
> >> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
> >> which maps to the "os-<service-type>-api:<resource>:<method>" format.
> >
> >
> > Thanks for explaining the justification, Michael.
> >
> > I'm curious if anyone has context on the "os-" part of the format? I've
> seen that pattern in a couple different projects. Does anyone know about
> its origin? Was it something we converted to our policy names because of
> API names/paths?
> >
> >>
> >>
> >> I selected it as it uses the service-type[1], references the API
> >> resource, and then the method. So it maps well to the API reference[2]
> >> for the service.
> >>
> >> [0] https://docs.openstack.org/octavia/latest/configuration/policy.html
> >> [1] https://service-types.openstack.org/
> >> [2]
> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
> >>
> >> Michael
> >> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
> >> >
> >> > So +1
> >> >
> >> >
> >> >
> >> > Tim
> >> >
> >> >
> >> >
> >> > From: Lance Bragstad <lbragstad@gmail.com>
> >> > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> >> > Date: Wednesday, 12 September 2018 at 20:43
> >> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, OpenStack Operators <
> openstack-operators@lists.openstack.org>
> >> > Subject: [openstack-dev] [all] Consistent policy names
> >> >
> >> >
> >> >
> >> > The topic of having consistent policy names has popped up a few times
> this week. Ultimately, if we are to move forward with this, we'll need a
> convention. To help with that a little bit I started an etherpad [0] that
> includes links to policy references, basic conventions *within* that
> service, and some examples of each. I got through quite a few projects this
> morning, but there are still a couple left.
> >> >
> >> >
> >> >
> >> > The idea is to look at what we do today and see what conventions we
> can come up with to move towards, which should also help us determine how
> much each convention is going to impact services (e.g. picking a convention
> that will cause 70% of services to rename policies).
> >> >
> >> >
> >> >
> >> > Please have a look and we can discuss conventions in this thread. If
> we come to agreement, I'll start working on some documentation in
> oslo.policy so that it's somewhat official because starting to renaming
> policies.
> >> >
> >> >
> >> >
> >> > [0] https://etherpad.openstack.org/p/consistent-policy-names
> >> >
> >> > _______________________________________________
> >> > OpenStack-operators mailing list
> >> > OpenStack-operators@lists.openstack.org
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
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").

On Sat, Sep 15, 2018 at 9:01 AM Morgan Fainberg <morgan.fainberg@gmail.com>
wrote:

> I am generally opposed to needlessly prefixing things with "os".
>
> I would advocate to drop it.
>
>
> On Fri, Sep 14, 2018, 20:17 Lance Bragstad <lbragstad@gmail.com> wrote:
>
>> Ok - yeah, I'm not sure what the history behind that is either...
>>
>> I'm mainly curious if that's something we can/should keep or if we are
>> opposed to dropping 'os' and 'api' from the convention (e.g.
>> load-balancer:loadbalancer:post as opposed to
>> os_load-balancer_api:loadbalancer:post) and just sticking with the
>> service-type?
>>
>> On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson <johnsomor@gmail.com>
>> wrote:
>>
>>> I don't know for sure, but I assume it is short for "OpenStack" and
>>> prefixing OpenStack policies vs. third party plugin policies for
>>> documentation purposes.
>>>
>>> I am guilty of borrowing this from existing code examples[0].
>>>
>>> [0]
>>> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html
>>>
>>> Michael
>>> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad <lbragstad@gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor@gmail.com>
>>> wrote:
>>> >>
>>> >> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
>>> >> which maps to the "os-<service-type>-api:<resource>:<method>" format.
>>> >
>>> >
>>> > Thanks for explaining the justification, Michael.
>>> >
>>> > I'm curious if anyone has context on the "os-" part of the format?
>>> I've seen that pattern in a couple different projects. Does anyone know
>>> about its origin? Was it something we converted to our policy names because
>>> of API names/paths?
>>> >
>>> >>
>>> >>
>>> >> I selected it as it uses the service-type[1], references the API
>>> >> resource, and then the method. So it maps well to the API reference[2]
>>> >> for the service.
>>> >>
>>> >> [0]
>>> https://docs.openstack.org/octavia/latest/configuration/policy.html
>>> >> [1] https://service-types.openstack.org/
>>> >> [2]
>>> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
>>> >>
>>> >> Michael
>>> >> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
>>> >> >
>>> >> > So +1
>>> >> >
>>> >> >
>>> >> >
>>> >> > Tim
>>> >> >
>>> >> >
>>> >> >
>>> >> > From: Lance Bragstad <lbragstad@gmail.com>
>>> >> > Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <openstack-dev@lists.openstack.org>
>>> >> > Date: Wednesday, 12 September 2018 at 20:43
>>> >> > To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>, OpenStack Operators <
>>> openstack-operators@lists.openstack.org>
>>> >> > Subject: [openstack-dev] [all] Consistent policy names
>>> >> >
>>> >> >
>>> >> >
>>> >> > The topic of having consistent policy names has popped up a few
>>> times this week. Ultimately, if we are to move forward with this, we'll
>>> need a convention. To help with that a little bit I started an etherpad [0]
>>> that includes links to policy references, basic conventions *within* that
>>> service, and some examples of each. I got through quite a few projects this
>>> morning, but there are still a couple left.
>>> >> >
>>> >> >
>>> >> >
>>> >> > The idea is to look at what we do today and see what conventions we
>>> can come up with to move towards, which should also help us determine how
>>> much each convention is going to impact services (e.g. picking a convention
>>> that will cause 70% of services to rename policies).
>>> >> >
>>> >> >
>>> >> >
>>> >> > Please have a look and we can discuss conventions in this thread.
>>> If we come to agreement, I'll start working on some documentation in
>>> oslo.policy so that it's somewhat official because starting to renaming
>>> policies.
>>> >> >
>>> >> >
>>> >> >
>>> >> > [0] https://etherpad.openstack.org/p/consistent-policy-names
>>> >> >
>>> >> > _______________________________________________
>>> >> > OpenStack-operators mailing list
>>> >> > OpenStack-operators@lists.openstack.org
>>> >> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >>
>>> >>
>>> __________________________________________________________________________
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe:
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> > _______________________________________________
>>> > OpenStack-operators mailing list
>>> > OpenStack-operators@lists.openstack.org
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
johnsom (from octavia) had a good idea, which was to use the service types
that are defined already [0].

I like this for three reasons, specifically. First, it's already a known
convention for services that we can just reuse. Second, it includes a
spacing convention (e.g. load-balancer vs load_balancer). Third,
it's relatively short since it doesn't include "os" or "api".

So long as there isn't any objection to that, we can start figuring out how
we want to do the method and resource parts. I pulled some policies into a
place where I could try and query them for specific patterns and existing
usage [1]. With the representation that I have (nova, neutron, glance,
cinder, keystone, mistral, and octavia):

- *create* is favored over post (105 occurrences to 7)
- *list* is favored over get_all (74 occurrences to 28)
- *update* is favored over put/patch (91 occurrences to 10)

From this perspective, using the HTTP method might be slightly redundant
for projects using the DocumentedRuleDefault object from oslo.policy since
it contains the URL and method for invoking the policy. It also might
differ depending on the service implementing the API (some might use put
instead of patch to update a resource). Conversely, using the HTTP method
in the policy name itself doesn't require use of DocumentedRuleDefault,
although its usage is still recommended.

Thoughts on using create, list, update, and delete as opposed to post, get,
put, patch, and delete in the naming convention?

[0] https://service-types.openstack.org/service-types.json
[1]
https://gist.github.com/lbragstad/5000b46f27342589701371c88262c35b#file-policy-names-yaml

On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad <lbragstad@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").
>
> On Sat, Sep 15, 2018 at 9:01 AM Morgan Fainberg <morgan.fainberg@gmail.com>
> wrote:
>
>> I am generally opposed to needlessly prefixing things with "os".
>>
>> I would advocate to drop it.
>>
>>
>> On Fri, Sep 14, 2018, 20:17 Lance Bragstad <lbragstad@gmail.com> wrote:
>>
>>> Ok - yeah, I'm not sure what the history behind that is either...
>>>
>>> I'm mainly curious if that's something we can/should keep or if we are
>>> opposed to dropping 'os' and 'api' from the convention (e.g.
>>> load-balancer:loadbalancer:post as opposed to
>>> os_load-balancer_api:loadbalancer:post) and just sticking with the
>>> service-type?
>>>
>>> On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson <johnsomor@gmail.com>
>>> wrote:
>>>
>>>> I don't know for sure, but I assume it is short for "OpenStack" and
>>>> prefixing OpenStack policies vs. third party plugin policies for
>>>> documentation purposes.
>>>>
>>>> I am guilty of borrowing this from existing code examples[0].
>>>>
>>>> [0]
>>>> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html
>>>>
>>>> Michael
>>>> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad <lbragstad@gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
>>>> >> which maps to the "os-<service-type>-api:<resource>:<method>" format.
>>>> >
>>>> >
>>>> > Thanks for explaining the justification, Michael.
>>>> >
>>>> > I'm curious if anyone has context on the "os-" part of the format?
>>>> I've seen that pattern in a couple different projects. Does anyone know
>>>> about its origin? Was it something we converted to our policy names because
>>>> of API names/paths?
>>>> >
>>>> >>
>>>> >>
>>>> >> I selected it as it uses the service-type[1], references the API
>>>> >> resource, and then the method. So it maps well to the API
>>>> reference[2]
>>>> >> for the service.
>>>> >>
>>>> >> [0]
>>>> https://docs.openstack.org/octavia/latest/configuration/policy.html
>>>> >> [1] https://service-types.openstack.org/
>>>> >> [2]
>>>> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
>>>> >>
>>>> >> Michael
>>>> >> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <Tim.Bell@cern.ch> wrote:
>>>> >> >
>>>> >> > So +1
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > Tim
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > From: Lance Bragstad <lbragstad@gmail.com>
>>>> >> > Reply-To: "OpenStack Development Mailing List (not for usage
>>>> questions)" <openstack-dev@lists.openstack.org>
>>>> >> > Date: Wednesday, 12 September 2018 at 20:43
>>>> >> > To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <openstack-dev@lists.openstack.org>, OpenStack Operators <
>>>> openstack-operators@lists.openstack.org>
>>>> >> > Subject: [openstack-dev] [all] Consistent policy names
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The topic of having consistent policy names has popped up a few
>>>> times this week. Ultimately, if we are to move forward with this, we'll
>>>> need a convention. To help with that a little bit I started an etherpad [0]
>>>> that includes links to policy references, basic conventions *within* that
>>>> service, and some examples of each. I got through quite a few projects this
>>>> morning, but there are still a couple left.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The idea is to look at what we do today and see what conventions
>>>> we can come up with to move towards, which should also help us determine
>>>> how much each convention is going to impact services (e.g. picking a
>>>> convention that will cause 70% of services to rename policies).
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > Please have a look and we can discuss conventions in this thread.
>>>> If we come to agreement, I'll start working on some documentation in
>>>> oslo.policy so that it's somewhat official because starting to renaming
>>>> policies.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > [0] https://etherpad.openstack.org/p/consistent-policy-names
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > OpenStack-operators mailing list
>>>> >> > OpenStack-operators@lists.openstack.org
>>>> >> >
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>> >>
>>>> >>
>>>> __________________________________________________________________________
>>>> >> OpenStack Development Mailing List (not for usage questions)
>>>> >> Unsubscribe:
>>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>> > _______________________________________________
>>>> > OpenStack-operators mailing list
>>>> > OpenStack-operators@lists.openstack.org
>>>> >
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
tl;dr
+1 consistent names
I would make the names mirror the API
... because the Operator setting them knows the API, not the code
Ignore the crazy names in Nova, I certainly hate them


Lance Bragstad <lbragstad@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@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@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").
>>
>
+1
The API is known as "compute" in api-ref, so the policy should be for
"compute", etc.

From: Lance Bragstad <lbragstad@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

Thanks,
John
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <john@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@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@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@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.

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"

May be we can make them consistent with <service-type>:<resource>:<action_with_snake_case> or any better opinion.

> From: Lance Bragstad <lbragstad@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

-gmann

> Thanks,John __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
Adding the operator list back in.

On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad <lbragstad@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@gmail.com>
> wrote:
>
>>
>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <gmann@ghanshyammann.com>
>> wrote:
>>
>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
>>> john@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
> On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad <lbragstad@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>
> >

My initial preference was the second format, but you make a good point here
about potential subactions. Either is fine with me - the main thing I would
love to see is consistency in format. But based on this part, I vote for option
2.

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

+1 thanks for working on this!


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com> wrote:

> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> <morgan.fainberg@gmail.com> wrote:
> >
> > 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
> +1 -- I think the ordering if `resource` comes before
> `action|subaction` will be more clean.
>

++

These are excellent points. I especially like being able to omit the
convention about plurality. Furthermore, I'd like to add that I think we
should make the resource singular (e.g., project instead or projects). For
example:

compute:server:list
compute:server:update
compute:server:create
compute:server:delete
compute:server:action:reboot
compute:server:action:confirm_resize (or confirm-resize)

Otherwise, someone might mistake compute:servers:get, as "list". This is
ultra-nick-picky, but something I thought of when seeing the usage of
"get_all" in policy names in favor of "list."

In summary, the new convention based on the most recent feedback should be:

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

Rules:

- service-type is always defined in the service types authority
- resources are always singular

Thanks to all for sticking through this tedious discussion. I appreciate it.


>
> /R
>
> Harry
> >
> > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad@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@gmail.com>
> wrote:
> >>>
> >>>
> >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
> gmann@ghanshyammann.com> wrote:
> >>>>
> >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> john@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote:
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com> wrote:
>
> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > <morgan.fainberg@gmail.com> wrote:
> > >
> > > 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
> > +1 -- I think the ordering if `resource` comes before
> > `action|subaction` will be more clean.
> >
>

Great idea. This is looking better and better.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
Alright - I've worked up the majority of what we have in this thread and
proposed a documentation patch for oslo.policy [0].

I think we're at the point where we can finish the rest of this discussion
in gerrit if folks are ok with that.

[0] https://review.openstack.org/#/c/606214/

On Fri, Sep 28, 2018 at 3:33 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:

> On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote:
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com>
> wrote:
> >
> > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > > <morgan.fainberg@gmail.com> wrote:
> > > >
> > > > 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
> > > +1 -- I think the ordering if `resource` comes before
> > > `action|subaction` will be more clean.
> > >
> >
>
> Great idea. This is looking better and better.
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <lbragstad@gmail.com> wrote ----
>
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com> wrote:
> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> <morgan.fainberg@gmail.com> wrote:
> >
> > 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
> +1 -- I think the ordering if `resource` comes before
> `action|subaction` will be more clean.
>
> ++
> These are excellent points. I especially like being able to omit the convention about plurality. Furthermore, I'd like to add that I think we should make the resource singular (e.g., project instead or projects). For example:
> compute:server:list
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize (or confirm-resize)

Do we need "action" word there? I think action name itself should convey the operation. IMO below notation without "äction" word looks clear enough. what you say?

compute:server:reboot
compute:server:confirm_resize

-gmann

>
> Otherwise, someone might mistake compute:servers:get, as "list". This is ultra-nick-picky, but something I thought of when seeing the usage of "get_all" in policy names in favor of "list."
> In summary, the new convention based on the most recent feedback should be:
> <service-type>:<resource>:<action>[:<subaction>]
> Rules:service-type is always defined in the service types authority
> resources are always singular
> Thanks to all for sticking through this tedious discussion. I appreciate it.
> /R
>
> Harry
> >
> > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad@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@gmail.com> wrote:
> >>>
> >>>
> >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
> >>>>
> >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <john@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@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
---- On Sat, 29 Sep 2018 07:23:30 +0900 Lance Bragstad <lbragstad@gmail.com> wrote ----
> Alright - I've worked up the majority of what we have in this thread and proposed a documentation patch for oslo.policy [0].
> I think we're at the point where we can finish the rest of this discussion in gerrit if folks are ok with that.
> [0] https://review.openstack.org/#/c/606214/

+1, thanks for that. let's start the discussion there.

-gmann

> On Fri, Sep 28, 2018 at 3:33 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
> On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote:
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com> wrote:
> >
> > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > > <morgan.fainberg@gmail.com> wrote:
> > > >
> > > > 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
> > > +1 -- I think the ordering if `resource` comes before
> > > `action|subaction` will be more clean.
> > >
> >
>
> Great idea. This is looking better and better.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gmann@ghanshyammann.com>
wrote:

> ---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbragstad@gmail.com> wrote ----
> >
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com>
> wrote:
> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > <morgan.fainberg@gmail.com> wrote:
> > >
> > > 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
> > +1 -- I think the ordering if `resource` comes before
> > `action|subaction` will be more clean.
> >
> > ++
> > These are excellent points. I especially like being able to omit the
> convention about plurality. Furthermore, I'd like to add that I think we
> should make the resource singular (e.g., project instead or projects). For
> example:
> > compute:server:list
> >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
>
> Do we need "action" word there? I think action name itself should convey
> the operation. IMO below notation without "äction" word looks clear enough.
> what you say?
>
> compute:server:reboot
> compute:server:confirm_resize
>

I agree. I simplified this in the current version up for review.


>
> -gmann
>
> >
> > Otherwise, someone might mistake compute:servers:get, as "list". This
> is ultra-nick-picky, but something I thought of when seeing the usage of
> "get_all" in policy names in favor of "list."
> > In summary, the new convention based on the most recent feedback should
> be:
> > <service-type>:<resource>:<action>[:<subaction>]
> > Rules:service-type is always defined in the service types authority
> > resources are always singular
> > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
> > /R
> >
> > Harry
> > >
> > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad@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@gmail.com>
> wrote:
> > >>>
> > >>>
> > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
> gmann@ghanshyammann.com> wrote:
> > >>>>
> > >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> john@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@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@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
Sending a follow up here quick.

The reviewers actively participating in [0] are nearing a conclusion.
Ultimately, the convention is going to be:

<service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]

Details about what that actually means can be found in the review [0]. Each
piece is denoted as being required or optional, along with examples. I
think this gives us a pretty good starting place, and the syntax is
flexible enough to support almost every policy naming convention we've
stumbled across.

Now is the time if you have any final input or feedback. Thanks for
sticking with the discussion.

Lance

[0] https://review.openstack.org/#/c/606214/


On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad <lbragstad@gmail.com> wrote:

>
> On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gmann@ghanshyammann.com>
> wrote:
>
>> ---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
>> lbragstad@gmail.com> wrote ----
>> >
>> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com>
>> wrote:
>> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>> > <morgan.fainberg@gmail.com> wrote:
>> > >
>> > > 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
>> > +1 -- I think the ordering if `resource` comes before
>> > `action|subaction` will be more clean.
>> >
>> > ++
>> > These are excellent points. I especially like being able to omit the
>> convention about plurality. Furthermore, I'd like to add that I think we
>> should make the resource singular (e.g., project instead or projects). For
>> example:
>> > compute:server:list
>> >
>> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
>> (or confirm-resize)
>>
>> Do we need "action" word there? I think action name itself should convey
>> the operation. IMO below notation without "äction" word looks clear enough.
>> what you say?
>>
>> compute:server:reboot
>> compute:server:confirm_resize
>>
>
> I agree. I simplified this in the current version up for review.
>
>
>>
>> -gmann
>>
>> >
>> > Otherwise, someone might mistake compute:servers:get, as "list". This
>> is ultra-nick-picky, but something I thought of when seeing the usage of
>> "get_all" in policy names in favor of "list."
>> > In summary, the new convention based on the most recent feedback
>> should be:
>> > <service-type>:<resource>:<action>[:<subaction>]
>> > Rules:service-type is always defined in the service types authority
>> > resources are always singular
>> > Thanks to all for sticking through this tedious discussion. I
>> appreciate it.
>> > /R
>> >
>> > Harry
>> > >
>> > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad@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@gmail.com> wrote:
>> > >>>
>> > >>>
>> > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
>> gmann@ghanshyammann.com> wrote:
>> > >>>>
>> > >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
>> john@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@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@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
---- On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <lbragstad@gmail.com> wrote ----
> Sending a follow up here quick.
> The reviewers actively participating in [0] are nearing a conclusion. Ultimately, the convention is going to be:
> <service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]
> Details about what that actually means can be found in the review [0]. Each piece is denoted as being required or optional, along with examples. I think this gives us a pretty good starting place, and the syntax is flexible enough to support almost every policy naming convention we've stumbled across.
> Now is the time if you have any final input or feedback. Thanks for sticking with the discussion.

Thanks Lance for working on this. Current version lgtm. I would like to see some operators feedback also if this standard policy name format is clear and easy understandable.

-gmann

> Lance
> [0] https://review.openstack.org/#/c/606214/
>
> On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad <lbragstad@gmail.com> wrote:
>
> On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
> ---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <lbragstad@gmail.com> wrote ----
> >
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com> wrote:
> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > <morgan.fainberg@gmail.com> wrote:
> > >
> > > 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
> > +1 -- I think the ordering if `resource` comes before
> > `action|subaction` will be more clean.
> >
> > ++
> > These are excellent points. I especially like being able to omit the convention about plurality. Furthermore, I'd like to add that I think we should make the resource singular (e.g., project instead or projects). For example:
> > compute:server:list
> > compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize (or confirm-resize)
>
> Do we need "action" word there? I think action name itself should convey the operation. IMO below notation without "äction" word looks clear enough. what you say?
>
> compute:server:reboot
> compute:server:confirm_resize
>
> I agree. I simplified this in the current version up for review.
> -gmann
>
> >
> > Otherwise, someone might mistake compute:servers:get, as "list". This is ultra-nick-picky, but something I thought of when seeing the usage of "get_all" in policy names in favor of "list."
> > In summary, the new convention based on the most recent feedback should be:
> > <service-type>:<resource>:<action>[:<subaction>]
> > Rules:service-type is always defined in the service types authority
> > resources are always singular
> > Thanks to all for sticking through this tedious discussion. I appreciate it.
> > /R
> >
> > Harry
> > >
> > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <lbragstad@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@gmail.com> wrote:
> > >>>
> > >>>
> > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
> > >>>>
> > >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <john@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@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@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Consistent policy names [ In reply to ]
It happened. Documentation is hot off the press and ready for you to read
[0]. As always, feel free to raise concerns, comments, or questions any
time.

I appreciate everyone's help in nailing this down.

[0]
https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies

On Sat, Oct 13, 2018 at 6:07 AM Ghanshyam Mann <gmann@ghanshyammann.com>
wrote:

> ---- On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <
> lbragstad@gmail.com> wrote ----
> > Sending a follow up here quick.
> > The reviewers actively participating in [0] are nearing a conclusion.
> Ultimately, the convention is going to be:
> >
> <service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]
> > Details about what that actually means can be found in the review [0].
> Each piece is denoted as being required or optional, along with examples. I
> think this gives us a pretty good starting place, and the syntax is
> flexible enough to support almost every policy naming convention we've
> stumbled across.
> > Now is the time if you have any final input or feedback. Thanks for
> sticking with the discussion.
>
> Thanks Lance for working on this. Current version lgtm. I would like to
> see some operators feedback also if this standard policy name format is
> clear and easy understandable.
>
> -gmann
>
> > Lance
> > [0] https://review.openstack.org/#/c/606214/
> >
> > On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad <lbragstad@gmail.com>
> wrote:
> >
> > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gmann@ghanshyammann.com>
> wrote:
> > ---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbragstad@gmail.com> wrote ----
> > >
> > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki@redhat.com>
> wrote:
> > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > > <morgan.fainberg@gmail.com> wrote:
> > > >
> > > > 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
> > > +1 -- I think the ordering if `resource` comes before
> > > `action|subaction` will be more clean.
> > >
> > > ++
> > > These are excellent points. I especially like being able to omit
> the convention about plurality. Furthermore, I'd like to add that I think
> we should make the resource singular (e.g., project instead or projects).
> For example:
> > > compute:server:list
> > >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
> >
> > Do we need "action" word there? I think action name itself should
> convey the operation. IMO below notation without "äction" word looks clear
> enough. what you say?
> >
> > compute:server:reboot
> > compute:server:confirm_resize
> >
> > I agree. I simplified this in the current version up for review.
> > -gmann
> >
> > >
> > > Otherwise, someone might mistake compute:servers:get, as "list".
> This is ultra-nick-picky, but something I thought of when seeing the usage
> of "get_all" in policy names in favor of "list."
> > > In summary, the new convention based on the most recent feedback
> should be:
> > > <service-type>:<resource>:<action>[:<subaction>]
> > > Rules:service-type is always defined in the service types authority
> > > resources are always singular
> > > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
> > > /R
> > >
> > > Harry
> > > >
> > > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <
> lbragstad@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@gmail.com> wrote:
> > > >>>
> > > >>>
> > > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
> gmann@ghanshyammann.com> wrote:
> > > >>>>
> > > >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> john@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@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@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@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@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@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@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@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@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@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@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@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>