[Openstack-operators] [openstack-dev] [all] Consistent policy names

Lance Bragstad lbragstad at gmail.com
Mon Sep 17 02:47:07 UTC 2018


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-operators/attachments/20180916/62677f7f/attachment.html>


More information about the OpenStack-operators mailing list