[Openstack-operators] _member_ role clarification
jpichon at redhat.com
Wed Nov 9 13:17:46 UTC 2016
On 9 November 2016 at 11:55, Justin Cattle <j at ocado.com> wrote:
> Apologies if this questions has been answered already, or is in some doc
> somewhere. Please point me in the right direction of so.
> I'm upgrading openstack from Juno to Mitaka, in steps. We role our own
> openstack using puppet, and have been using identity v3 in Juno with domains
> via an ldap backend.
> The upgrade process is largely created, tested and working, but not rolled
> out across our production sites yet.
> However, I notice when I create a new cloud using openstack Mitaka from
> scratch, not upgraded from Juno, the _member_ role is no longer created
> automatically when users are assigned to projects [ tenants in old money ].
> I'm pretty sure this was happening in Juno, and the Juno docs seem to
> confirm it.
> I believe horizon at least was using this role to allow users access.
> I've noticed this because we have scripts to automate some user/group stuff,
> and the have some usage of the _member_ role hard coded atm. They are
> failing, as the role doesn't exist on non-upgraded clouds :)
> So I would like some advice/clarification on what the situation is.
> What else, if anything, was the _member_ role used for? heat maybe?
> Is the _member_ role no longer required at all, not even by horizon?
> If it's no longer required, is it safe or desirable to remove the _member_
> role from upgraded clouds?
I can't answer all of your questions, but you might find bug #1635306
 interesting. It has some additional background information and the
role still seems needed at least by Horizon (unless the default role
name is changed manually in the settings). The related patch merged in
Ocata and Newton, but from your comments it sounds like perhaps a
backport is needed for Mitaka as well?
More information about the OpenStack-operators