[openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Lance Bragstad lbragstad at gmail.com
Fri May 26 14:05:51 UTC 2017


On Fri, May 26, 2017 at 5:32 AM, Sean Dague <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


>
>         -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/0a019e31/attachment.html>


More information about the OpenStack-dev mailing list