On Fri, May 26, 2017 at 9:31 AM, Sean Dague <[email protected]> wrote: > On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague <[email protected] > > <mailto:[email protected]>> 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 > > Personally, as someone that has to think about consuming oslo.context, I > really don't want > "scope" as a context option. Because now it means role means something > different. > > I want the context to say: > > { > "user": "me!" > "project": "some_fun_work", > "project_roles": ["member"], > "is_admin": True, > "roles": ["admin", "auditor"], > .... > } > > That's something I can imagine understanding. Because context switching > on scope and conditionally doing different things in code depending on > that is something that's going to cause bugs. It's hard code to not get > wrong. > > 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?
> -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
