On Fri, May 26, 2017 at 5:32 AM, Sean Dague <s...@dague.net> wrote: > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did go for option 3. > > > > Do we have an agreed non-distruptive upgrade path mapped out yet? (For > > any of the options) We spoke about fallback rules you pass but with a > > warning to give us a smoother transition. I think that's my main > > objection with the existing patches, having to tell all admins to get > > their token for a different project, and give them roles in that > > project, all before being able to upgrade. > > I definitely think the double migration is a good reason to just do this > thing right the first time. > > My biggest real concern with is_admin_project (and the service project), > is that it's not very explicit. It's mostly a way to trick the current > plumbing into acting a different way. Which is fine if you are a > deployer and need to create this behavior with the existing codebase you > have. Which seems to have all come down to their being a > misunderstanding of what Roles were back in 2012, and the two camps went > off in different directions (roles really being project scoped, and > roles meaning global). > > It would be really great if the inflated context we got was "roles: x, > y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware > and oslo.context might be weaving some magic there). I honestly think > that until we've got a very clear separation at that level, it's going > to be really tough to get policy files in projects to be any more > sensible in their defaults. Leaking is_admin_project all the way through > to a service and having them have to consider it for their policy (which > we do with the context today) definitely feels like a layer violation. >
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. [0] https://review.openstack.org/#/c/464763 > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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