Open Stack

On 05/26/2017 10:05 AM, Lance Bragstad wrote:
> 
> 
> On Fri, May 26, 2017 at 5:32 AM, Sean Dague <sean at dague.net
> <mailto:sean at 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

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.

	-Sean

-- 
Sean Dague
http://dague.net