[Openstack-operators] [openstack-dev] [all] Consistent policy names
Lance Bragstad
lbragstad at gmail.com
Tue Oct 16 15:11:19 UTC 2018
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, Oct 13, 2018 at 6:07 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:
> ---- On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <
> lbragstad at gmail.com> wrote ----
> > Sending a follow up here quick.
> > The reviewers actively participating in [0] are nearing a conclusion.
> Ultimately, the convention is going to be:
> >
> <service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]
> > Details about what that actually means can be found in the review [0].
> Each piece is denoted as being required or optional, along with examples. I
> think this gives us a pretty good starting place, and the syntax is
> flexible enough to support almost every policy naming convention we've
> stumbled across.
> > Now is the time if you have any final input or feedback. Thanks for
> sticking with the discussion.
>
> Thanks Lance for working on this. Current version lgtm. I would like to
> see some operators feedback also if this standard policy name format is
> clear and easy understandable.
>
> -gmann
>
> > Lance
> > [0] https://review.openstack.org/#/c/606214/
> >
> > On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad <lbragstad at gmail.com>
> wrote:
> >
> > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
> > ---- On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbragstad at gmail.com> wrote ----
> > >
> > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki <hrybacki at redhat.com>
> wrote:
> > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > > <morgan.fainberg at gmail.com> 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 plurality depending on action type.
> > > >
> > > > I propose we consider
> > > >
> > > > <service-type>:<resource>:<action>[:<subaction>]
> > > >
> > > > Example for keystone (note, action names below are strictly
> examples I am fine with whatever form those actions take):
> > > > identity:projects:create
> > > > identity:projects:delete
> > > > identity:projects:list
> > > > identity:projects:get
> > > >
> > > > It keeps things simple and consistent when you're looking
> through overrides / defaults.
> > > > --Morgan
> > > +1 -- I think the ordering if `resource` comes before
> > > `action|subaction` will be more clean.
> > >
> > > ++
> > > These are excellent points. I especially like being able to omit
> the convention about plurality. Furthermore, I'd like to add that I think
> we should make the resource singular (e.g., project instead or projects).
> For example:
> > > compute:server:list
> > >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
> >
> > Do we need "action" word there? I think action name itself should
> convey the operation. IMO below notation without "äction" word looks clear
> enough. what you say?
> >
> > compute:server:reboot
> > compute:server:confirm_resize
> >
> > I agree. I simplified this in the current version up for review.
> > -gmann
> >
> > >
> > > Otherwise, someone might mistake compute:servers:get, as "list".
> This is ultra-nick-picky, but something I thought of when seeing the usage
> of "get_all" in policy names in favor of "list."
> > > In summary, the new convention based on the most recent feedback
> should be:
> > > <service-type>:<resource>:<action>[:<subaction>]
> > > Rules:service-type is always defined in the service types authority
> > > resources are always singular
> > > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
> > > /R
> > >
> > > Harry
> > > >
> > > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <
> lbragstad at gmail.com> 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:
> > > >>
> > > >> <service-type>:<action>:<resource>
> > > >>
> > > >> or
> > > >>
> > > >> <service-type>:<action>_<resource>
> > > >>
> > > >> Where <service-type> is the corresponding service type of the
> project [0], and <action> is either create, get, list, update, or delete. I
> think decoupling the method from the policy name should aid in consistency,
> regardless of the underlying implementation. The HTTP method specifics can
> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
> > > >>
> > > >> I think the plurality of the resource should default to what
> makes sense for the operation being carried out (e.g., list:foobars,
> create:foobar).
> > > >>
> > > >> I don't mind the first one because it's clear about what the
> delimiter is and it doesn't look weird when projects have something like:
> > > >>
> > > >> <service-type>:<action>:<subaction>:<resource>
> > > >>
> > > >> If folks are ok with this, I can start working on some
> documentation that explains the motivation for this. Afterward, we can
> figure out how we want to track this work.
> > > >>
> > > >> What color do you want the shed to be?
> > > >>
> > > >> [0] https://service-types.openstack.org/service-types.json
> > > >> [1]
> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
> > > >>
> > > >> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad <
> lbragstad at gmail.com> wrote:
> > > >>>
> > > >>>
> > > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
> gmann at ghanshyammann.com> wrote:
> > > >>>>
> > > >>>> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> john at 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 <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").
> > > >>>> > +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].
> > > >>>
> > > >>> [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 <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
> > > >>>>
> > > >>>> + 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.
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> -gmann
> > > >>>>
> > > >>>> > Thanks,John
> __________________________________________________________________________
> > > >>>> > OpenStack Development Mailing List (not for usage
> questions)
> > > >>>> > Unsubscribe:
> OpenStack-dev-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181016/1ab9dc6a/attachment.html>
More information about the OpenStack-operators
mailing list