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 <gm...@ghanshyammann.com> wrote: > ---- On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad < > lbrags...@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 <lbrags...@gmail.com> > wrote: > > > > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann <gm...@ghanshyammann.com> > 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 <hryba...@redhat.com> > wrote: > > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > > > <morgan.fainb...@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 < > lbrags...@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 < > 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]. > > > >>> > > > >>> [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. > > > >>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> -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 > > > > > > > __________________________________________________________________________ > > > 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-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > > __________________________________________________________________________ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators