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