<div dir="ltr"><div dir="ltr"><div dir="ltr">johnsom (from octavia) had a good idea, which was to use the service types that are defined already [0].<div><br></div><div>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".</div><div><br></div><div>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):</div><div><br></div><div>- <b>create</b> is favored over post (105 occurrences to 7)</div><div>- <b>list</b> is favored over get_all (74 occurrences to 28)</div><div>- <b>update</b> is favored over put/patch (91 occurrences to 10)</div><div><br></div><div>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.</div><div><br></div><div>Thoughts on using create, list, update, and delete as opposed to post, get, put, patch, and delete in the naming convention?</div><div><br></div><div>[0] <a href="https://service-types.openstack.org/service-types.json">https://service-types.openstack.org/service-types.json</a></div><div>[1] <a href="https://gist.github.com/lbragstad/5000b46f27342589701371c88262c35b#file-policy-names-yaml">https://gist.github.com/lbragstad/5000b46f27342589701371c88262c35b#file-policy-names-yaml</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If we consider dropping "os", should we entertain dropping "api", too? Do we have a good reason to keep "api"?<div><br></div><div>I wouldn't be opposed to simple service types (e.g "compute" or "loadbalancer").</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 15, 2018 at 9:01 AM Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I am generally opposed to needlessly prefixing things with "os".<div dir="auto"><br></div><div dir="auto">I would advocate to drop it.</div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 14, 2018, 20:17 Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok - yeah, I'm not sure what the history behind that is either...<div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson <<a href="mailto:johnsomor@gmail.com" rel="noreferrer" target="_blank">johnsomor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't know for sure, but I assume it is short for "OpenStack" and<br>
prefixing OpenStack policies vs. third party plugin policies for<br>
documentation purposes.<br>
<br>
I am guilty of borrowing this from existing code examples[0].<br>
<br>
[0] <a href="http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html" rel="noreferrer noreferrer" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html</a><br>
<br>
Michael<br>
On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad <<a href="mailto:lbragstad@gmail.com" rel="noreferrer" target="_blank">lbragstad@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson <<a href="mailto:johnsomor@gmail.com" rel="noreferrer" target="_blank">johnsomor@gmail.com</a>> wrote:<br>
>><br>
>> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"<br>
>> which maps to the "os-<service-type>-api:<resource>:<method>" format.<br>
><br>
><br>
> Thanks for explaining the justification, Michael.<br>
><br>
> 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?<br>
><br>
>><br>
>><br>
>> I selected it as it uses the service-type[1], references the API<br>
>> resource, and then the method. So it maps well to the API reference[2]<br>
>> for the service.<br>
>><br>
>> [0] <a href="https://docs.openstack.org/octavia/latest/configuration/policy.html" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/octavia/latest/configuration/policy.html</a><br>
>> [1] <a href="https://service-types.openstack.org/" rel="noreferrer noreferrer" target="_blank">https://service-types.openstack.org/</a><br>
>> [2] <a href="https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer" rel="noreferrer noreferrer" target="_blank">https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer</a><br>
>><br>
>> Michael<br>
>> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell <<a href="mailto:Tim.Bell@cern.ch" rel="noreferrer" target="_blank">Tim.Bell@cern.ch</a>> wrote:<br>
>> ><br>
>> > So +1<br>
>> ><br>
>> ><br>
>> ><br>
>> > Tim<br>
>> ><br>
>> ><br>
>> ><br>
>> > From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" rel="noreferrer" target="_blank">lbragstad@gmail.com</a>><br>
>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" rel="noreferrer" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> > Date: Wednesday, 12 September 2018 at 20:43<br>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" rel="noreferrer" target="_blank">openstack-dev@lists.openstack.org</a>>, OpenStack Operators <<a href="mailto:openstack-operators@lists.openstack.org" rel="noreferrer" target="_blank">openstack-operators@lists.openstack.org</a>><br>
>> > Subject: [openstack-dev] [all] Consistent policy names<br>
>> ><br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><br>
>> ><br>
>> ><br>
>> > 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).<br>
>> ><br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><br>
>> ><br>
>> ><br>
>> > [0] <a href="https://etherpad.openstack.org/p/consistent-policy-names" rel="noreferrer noreferrer" target="_blank">https://etherpad.openstack.org/p/consistent-policy-names</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-operators mailing list<br>
>> > <a href="mailto:OpenStack-operators@lists.openstack.org" rel="noreferrer" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" rel="noreferrer" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>
</blockquote></div>