It happened. Documentation is hot off the press and ready for you to read
[0]. As always, feel free to raise concerns, comments, or questions any
time.
I appreciate everyone's help in nailing this down.
[0]
https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies
On Sat,
On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad
wrote
> Sending a follow up here quick.
> The reviewers actively participating in [0] are nearing a conclusion.
> Ultimately, the convention is going to be:
>
> :[:][:]:[:]
> Details about what that actually means can be
Sending a follow up here quick.
The reviewers actively participating in [0] are nearing a conclusion.
Ultimately, the convention is going to be:
:[:][:]:[:]
Details about what that actually means can be found in the review [0]. Each
piece is denoted as being required or optional, along with
On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann
wrote:
> On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote
> >
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki
> wrote:
> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > wrote:
> > >
> > >
On Sat, 29 Sep 2018 07:23:30 +0900 Lance Bragstad
wrote
> Alright - I've worked up the majority of what we have in this thread and
> proposed a documentation patch for oslo.policy [0].
> I think we're at the point where we can finish the rest of this discussion
> in gerrit if
On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad
wrote
>
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote:
> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> wrote:
> >
> > Ideally I would like to see it in the form of least specific to most
> specific. But more
On Fri, 21 Sep 2018 23:13:02 +0900 Lance Bragstad
wrote
>
> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann
> wrote:
> On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt
> wrote
> > tl;dr+1 consistent names
> > I would make the names mirror the API... because
Alright - I've worked up the majority of what we have in this thread and
proposed a documentation patch for oslo.policy [0].
I think we're at the point where we can finish the rest of this discussion
in gerrit if folks are ok with that.
[0] https://review.openstack.org/#/c/606214/
On Fri, Sep
On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote:
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote:
>
> > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > wrote:
> > >
> > > Ideally I would like to see it in the form of least specific to most
> > specific. But more
On Fri, Sep 28, 2018 at 2:54 PM Lance Bragstad wrote:
>
>
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote:
>>
>> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>> wrote:
>> >
>> > Ideally I would like to see it in the form of least specific to most
>> > specific. But more importantly in
On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote:
> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> wrote:
> >
> > Ideally I would like to see it in the form of least specific to most
> specific. But more importantly in a way that there is no additional
> delimiters between the service
On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
wrote:
>
> Ideally I would like to see it in the form of least specific to most
> specific. But more importantly in a way that there is no additional
> delimiters between the service type and the resource. Finally, I do not like
> the change of
Ideally I would like to see it in the form of least specific to most
specific. But more importantly in a way that there is no additional
delimiters between the service type and the resource. Finally, I do not
like the change of plurality depending on action type.
I propose we consider
*::[:]*
> On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad wrote:
>
> > Bumping this thread again and proposing two conventions based on the
> > discussion here. I propose we decide on one of the two following
> > conventions:
> >
> > *::*
> >
> > or
> >
> > *:_*
> >
> > Where is the corresponding
Adding the operator list back in.
On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad wrote:
> Bumping this thread again and proposing two conventions based on the
> discussion here. I propose we decide on one of the two following
> conventions:
>
> *::*
>
> or
>
> *:_*
>
> Where is the
Bumping this thread again and proposing two conventions based on the
discussion here. I propose we decide on one of the two following
conventions:
*::*
or
*:_*
Where is the corresponding service type of the project [0],
and is either create, get, list, update, or delete. I think
decoupling
On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann
wrote:
> On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> j...@johngarbutt.com> wrote
> > tl;dr+1 consistent names
> > I would make the names mirror the API... because the Operator setting
> them knows the API, not the codeIgnore the
On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt
wrote
> tl;dr+1 consistent names
> I would make the names mirror the API... because the Operator setting them
> knows the API, not the codeIgnore the crazy names in Nova, I certainly hate
> them
Big +1 on consistent naming which
tl;dr
+1 consistent names
I would make the names mirror the API
... because the Operator setting them knows the API, not the code
Ignore the crazy names in Nova, I certainly hate them
Lance Bragstad wrote:
> I'm curious if anyone has context on the "os-" part of the format?
My memory of the
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
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
wrote:
> I am generally opposed to needlessly
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 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
>
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
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]
On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson wrote:
> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
> which maps to the "os--api::" format.
>
Thanks for explaining the justification, Michael.
I'm curious if anyone has context on the "os-" part of the format? I've
seen
In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
which maps to the "os--api::" format.
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]
26 matches
Mail list logo
