<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 9:31 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/26/2017 10:05 AM, Lance Bragstad wrote:<br>
><br>
><br>
> On Fri, May 26, 2017 at 5:32 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
><br>
>     On 05/26/2017 03:44 AM, John Garbutt wrote:<br>
>     > +1 on not forcing Operators to transition to something new twice, even<br>
>     > if we did go for option 3.<br>
>     ><br>
>     > Do we have an agreed non-distruptive upgrade path mapped out yet? (For<br>
>     > any of the options) We spoke about fallback rules you pass but with a<br>
>     > warning to give us a smoother transition. I think that's my main<br>
>     > objection with the existing patches, having to tell all admins to get<br>
>     > their token for a different project, and give them roles in that<br>
>     > project, all before being able to upgrade.<br>
><br>
>     I definitely think the double migration is a good reason to just do this<br>
>     thing right the first time.<br>
><br>
>     My biggest real concern with is_admin_project (and the service project),<br>
>     is that it's not very explicit. It's mostly a way to trick the current<br>
>     plumbing into acting a different way. Which is fine if you are a<br>
>     deployer and need to create this behavior with the existing codebase you<br>
>     have. Which seems to have all come down to their being a<br>
>     misunderstanding of what Roles were back in 2012, and the two camps went<br>
>     off in different directions (roles really being project scoped, and<br>
>     roles meaning global).<br>
><br>
>     It would be really great if the inflated context we got was "roles: x,<br>
>     y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware<br>
>     and oslo.context might be weaving some magic there). I honestly think<br>
>     that until we've got a very clear separation at that level, it's going<br>
>     to be really tough to get policy files in projects to be any more<br>
>     sensible in their defaults. Leaking is_admin_project all the way through<br>
>     to a service and having them have to consider it for their policy (which<br>
>     we do with the context today) definitely feels like a layer violation.<br>
><br>
><br>
> This is another good point. If we can ensure projects rely on<br>
> oslo.context to get scope information in a canonical form (like<br>
> context.scope == 'global' or context.scope == 'project') that might make<br>
> consuming all this easier. But it does require us to ensure oslo.context<br>
> does the right thing with various token types. I included some of that<br>
> information in the spec [0] but I didn't go into great detail. I thought<br>
> about adding it to the keystone spec but wasn't sure if that would be<br>
> the right place for it.<br>
><br>
> [0] <a href="https://review.openstack.org/#/c/464763" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/464763</a><br>
<br>
</div></div>Personally, as someone that has to think about consuming oslo.context, I<br>
really don't want<br>
"scope" as a context option. Because now it means role means something<br>
different.<br>
<br>
I want the context to say:<br>
<br>
{<br>
   "user": "me!"<br>
   "project": "some_fun_work",<br>
   "project_roles": ["member"],<br>
   "is_admin": True,<br>
   "roles": ["admin", "auditor"],<br>
   ....<br>
}<br>
<br>
That's something I can imagine understanding. Because context switching<br>
on scope and conditionally doing different things in code depending on<br>
that is something that's going to cause bugs. It's hard code to not get<br>
wrong.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Interesting - I guess the way I was thinking about it was on a per-token basis, since today you can't have a single token represent multiple scopes. Would it be unreasonable to have oslo.context build this information based on multiple tokens from the same user, or is that a bad idea?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>