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

Sean Dague sean at dague.net
Fri May 26 10:32:31 UTC 2017

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.


Sean Dague

More information about the OpenStack-dev mailing list