Open Stack

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 <lbragstad at gmail.com> wrote:
> I'm curious if anyone has context on the "os-" part of the format?

My memory of the Nova policy mess...
* Nova's policy rules traditionally followed the patterns of the code
** Yes, horrible, but it happened.
* The code used to have the OpenStack API and the EC2 API, hence the "os"
* API used to expand with extensions, so the policy name is often based on
extensions
** note most of the extension code has now gone, including lots of related
policies
* Policy in code was focused on getting us to a place where we could rename
policy
** Whoop whoop by the way, it feels like we are really close to something
sensible now!

Lance Bragstad <lbragstad at gmail.com> wrote:

> Thoughts on using create, list, update, and delete as opposed to post,
> get, put, patch, and delete in the naming convention?
>

I could go either way as I think about "list servers" in the API.
But my preference is for the URL stub and POST, GET, etc.

 On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad <lbragstad at gmail.com> wrote:

> 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").
>>
>
+1
The API is known as "compute" in api-ref, so the policy should be for
"compute", etc.

From: Lance Bragstad <lbragstad at gmail.com>
> The topic of having consistent policy names has popped up a few times
this week.

I would love to have this nailed down before we go through all the policy
rules again. In my head I hope in Nova we can go through each policy rule
and do the following:

* move to new consistent policy name, deprecate existing name
* hardcode scope check to project, system or user
** (user, yes... keypairs, yuck, but its how they work)
** deprecate in rule scope checks, which are largely bogus in Nova anyway
* make read/write/admin distinction
** therefore adding the "noop" role, amount other things

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180920/2be0202c/attachment.html>