<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 5:32 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">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>
</span>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></blockquote><div><br></div><div>This is another good point. If we can ensure projects rely on oslo.context to get scope information in a canonical form (like context.scope == 'global' or context.scope == 'project') that might make consuming all this easier. But it does require us to ensure oslo.context does the right thing with various token types. I included some of that information in the spec [0] but I didn't go into great detail. I thought about adding it to the keystone spec but wasn't sure if that would be the right place for it.</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/464763">https://review.openstack.org/#/c/464763</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
        -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>
<span class="gmail-">OpenStack Development Mailing List (not for usage questions)<br>
</span>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>
</blockquote></div><br></div></div>