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.fainb...@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 <lbrags...@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 <johnso...@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 <lbrags...@gmail.com> >>> wrote: >>> > >>> > >>> > >>> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <johnso...@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.b...@cern.ch> wrote: >>> >> > >>> >> > So +1 >>> >> > >>> >> > >>> >> > >>> >> > Tim >>> >> > >>> >> > >>> >> > >>> >> > From: Lance Bragstad <lbrags...@gmail.com> >>> >> > Reply-To: "OpenStack Development Mailing List (not for usage >>> questions)" <openstack-...@lists.openstack.org> >>> >> > Date: Wednesday, 12 September 2018 at 20:43 >>> >> > To: "OpenStack Development Mailing List (not for usage questions)" < >>> openstack-...@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-requ...@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-requ...@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-requ...@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
