Open Stack

On Fri, May 26, 2017 at 9:31 AM, Sean Dague <sean at dague.net> wrote:

> 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.
>
>
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170526/cf87dfd5/attachment.html>