---- 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 crazy names in Nova, I certainly hate
> them
Big +1 on consistent naming which will help operator as well as developer to
maintain those.
>
> Lance Bragstad <lbrags...@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 <lbrags...@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 <lbrags...@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").
> +1The API is known as "compute" in api-ref, so the policy should be for
> "compute", etc.
Agree on mapping the policy name with api-ref as much as possible. Other than
policy name having 'os-', we have 'os-' in resource name also in nova API url
like /os-agents, /os-aggregates etc (almost every resource except servers ,
flavors). As we cannot get rid of those from API url, we need to keep the same
in policy naming too? or we can have policy name like
compute:agents:create/post but that mismatch from api-ref where agents resource
url is os-agents.
Also we have action API (i know from nova not sure from other services) like
POST /servers/{server_id}/action {addSecurityGroup} and their current policy
name is all inconsistent. few have policy name including their resource name
like "os_compute_api:os-flavor-access:add_tenant_access", few has 'action' in
policy name like "os_compute_api:os-admin-actions:reset_state" and few has
direct action name like "os_compute_api:os-console-output"
May be we can make them consistent with
<service-type>:<resource>:<action_with_snake_case> or any better opinion.
> From: Lance Bragstad <lbrags...@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
+ policy granularity.
It is good idea to make the policy improvement all together and for all rules
as you mentioned. But my worries is how much load it will be on operator side
to migrate all policy rules at same time? What will be the deprecation period
etc which i think we can discuss on proposed spec -
https://review.openstack.org/#/c/547850
-gmann
> Thanks,John
> __________________________________________________________________________
> 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
