<div dir="ltr">Adding the operator list back in. </div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">Bumping this thread again and proposing two conventions based on the discussion here. I propose we decide on one of the two following conventions:<div><br></div><div><b><service-type>:<action>:<resource></b></div><div><br></div><div>or </div><div><br></div><div><b><service-type>:<action>_<resource></b></div><div><br></div><div>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].</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div><br></div><div><service-type>:<action>:<subaction>:<resource></div><div><br></div><div>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.</div><div><br></div><div>What color do you want the shed to be?</div><div><br></div><div>[0] <a href="https://service-types.openstack.org/service-types.json" target="_blank">https://service-types.openstack.org/service-types.json</a></div><div>[1] <a href="https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule" target="_blank">https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr"><span style="background-color:rgb(255,255,255)">On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>> wrote:<br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="background-color:rgb(255,255,255)"> ---- On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote ---- <br>
> tl;dr+1 consistent names<br>
> 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<br>
<br>
Big +1 on consistent naming which will help operator as well as developer to maintain those. <br>
<br>
> <br>
> Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<br>
> > I'm curious if anyone has context on the "os-" part of the format?<br>
> <br>
> My memory of the Nova policy mess...* Nova's policy rules traditionally followed the patterns of the code<br>
> ** 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!<br>
> Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<br>
> Thoughts on using create, list, update, and delete as opposed to post, get, put, patch, and delete in the naming convention?<br>
> 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.<br>
> On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> 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").<br>
> +1The API is known as "compute" in api-ref, so the policy should be for "compute", etc.<br>
<br>
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.<br></span></blockquote><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><div><span style="background-color:rgb(255,255,255)">Good question. I think this depends on how the service does policy enforcement.</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">I know we did something like this in keystone, which required policy names and method names to be the same:</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)"> "identity:list_users": "..."</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">Because the initial implementation of policy enforcement used a decorator like this:</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)"> from keystone import controller</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)"> @controller.protected</span></div><div><span style="background-color:rgb(255,255,255)"> def list_users(self):</span></div><div><span style="background-color:rgb(255,255,255)"> ...</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">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.</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">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.</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">Hopefully, that helps explain why we needed them to match.</span></div></div><div><span style="background-color:rgb(255,255,255)"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span style="background-color:rgb(255,255,255)"><br>
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"<br></span></blockquote><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><div><span style="background-color:rgb(255,255,255)">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].</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">[0] <a href="https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-actions-volumes-action" target="_blank">https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-actions-volumes-action</a></span></div></div><div><span style="background-color:rgb(255,255,255)"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span style="background-color:rgb(255,255,255)"><br>
May be we can make them consistent with <service-type>:<resource>:<action_with_snake_case> or any better opinion. <br>
<br>
> From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>>> The topic of having consistent policy names has popped up a few times this week.<br>
> <br>
> 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:<br>
> * 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<br>
<br>
+ policy granularity. <br>
<br>
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 - <a href="https://review.openstack.org/#/c/547850" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/547850</a></span></blockquote><div><br></div><div><div><span style="background-color:rgb(255,255,255)">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.</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">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.</span></div></div><div><span style="background-color:rgb(255,255,255)"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="background-color:rgb(255,255,255)"><br>
<br>
-gmann<br>
<br>
> Thanks,John __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>