---- On Fri, 21 Sep 2018 23:13:02 +0900 Lance Bragstad <lbrags...@gmail.com>
wrote ----
>
> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <gm...@ghanshyammann.com>
> 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 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.
>
> Good question. I think this depends on how the service does policy
> enforcement.
> I know we did something like this in keystone, which required policy names
> and method names to be the same:
> "identity:list_users": "..."
> Because the initial implementation of policy enforcement used a decorator
> like this:
> from keystone import controller
> @controller.protected def list_users(self): ...
> Having the policy name the same as the method name made it easier for the
> decorator implementation to resolve the policy needed to protect the API
> because it just looked at the name of the wrapped method. The advantage was
> that it was easy to implement new APIs because you only needed to add a
> policy, implement the method, and make sure you decorate the implementation.
> While this worked, we are moving away from it entirely. The decorator
> implementation was ridiculously complicated. Only a handful of keystone
> developers understood it. With the addition of system-scope, it would have
> only become more convoluted. It also enables a much more copy-paste pattern
> (e.g., so long as I wrap my method with this decorator implementation,
> things should work right?). Instead, we're calling enforcement within the
> controller implementation to ensure things are easier to understand. It
> requires developers to be cognizant of how different token types affect the
> resources within an API. That said, coupling the policy name to the method
> name is no longer a requirement for keystone.
> Hopefully, that helps explain why we needed them to match.
> 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"
>
> Since the actions API relies on the request body and uses a single HTTP
> method, does it make sense to have the HTTP method in the policy name? It
> feels redundant, and we might be able to establish a convention that's more
> meaningful for things like action APIs. It looks like cinder has a similar
> pattern [0].
Yes, HTTP method is not necessary to be in action policy. action name itself
should be self explanatory.
> [0]
> https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-actions-volumes-action
>
> 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
> Yeah, that's another valid concern. I know at least one operator has weighed
> in already. I'm curious if operators have specific input here.
> It ultimately depends on if they override existing policies or not. If a
> deployment doesn't have any overrides, it should be a relatively simple
> change for operators to consume.
Agree that non-override policy will be ok for name change cases. But still they
will be effected much when default roles will be changed.
-gmann
>
> -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
> __________________________________________________________________________
> 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
