Open Stack

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 at gmail.com> wrote:

> If we consider dropping "os", should we entertain dropping "api", too? Do
> we have a good reason to keep "api"?
>
> I wouldn't be opposed to simple service types (e.g "compute" or
> "loadbalancer").
>
> On Sat, Sep 15, 2018 at 9:01 AM Morgan Fainberg <morgan.fainberg at 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 at 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 at 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 at gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnsomor at 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 at cern.ch> wrote:
>>>> >> >
>>>> >> > So +1
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > Tim
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > From: Lance Bragstad <lbragstad at gmail.com>
>>>> >> > Reply-To: "OpenStack Development Mailing List (not for usage
>>>> questions)" <openstack-dev at lists.openstack.org>
>>>> >> > Date: Wednesday, 12 September 2018 at 20:43
>>>> >> > To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <openstack-dev at lists.openstack.org>, OpenStack Operators <
>>>> openstack-operators at 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 at 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 at lists.openstack.org?subject:unsubscribe
>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>> > _______________________________________________
>>>> > OpenStack-operators mailing list
>>>> > OpenStack-operators at 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 at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180919/11daaf6b/attachment.html>