Open Stack

----- Original Message -----
> From: "Adam Young" <ayoung at redhat.com>
> To: openstack at lists.openstack.org
> 
> On 06/14/2014 05:59 PM, Steve Gordon wrote:
> > ----- Original Message -----
> >> From: "Steve Gordon" <sgordon at redhat.com>
> >> To: "Mike Spreitzer" <mspreitz at us.ibm.com>
> >>
> >> ----- Original Message -----
> >>> From: "Mike Spreitzer" <mspreitz at us.ibm.com>
> >>> To: "Steve Gordon" <sgordon at redhat.com>
> >>>
> >>> Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 03:22:51 PM:
> >>>
> >>>>> From: "Mike Spreitzer" <mspreitz at us.ibm.com>
> >>>>> To: "Steve Gordon" <sgordon at redhat.com>
> >>>>>
> >>>>> Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 12:43:48 PM:
> >>>>> ...
> >>>>>> Yes, it's supposed to be created by the db creation/migration
> >>>>>> scripts if it's not there (since Grizzly if I recall correctly).
> >>>>> But there is also the role spelled "Member".  Why both?
> >>>>>
> >>>>> Thanks,
> >>>>> Mike
> >>>> When Keystone started creating a "_member_" role automatically in
> >>>> Grizzly there was a lag period before other projects, particularly
> >>>> Horizon which defaulted to "Member" at the time, started using the
> >>>> new role. As a result the installation guide, and even most
> >>>> automated deployment tools, which previously had to create the role
> >>>> as part of installation still created a "Member" role because that
> >>>> was what Horizon expected and there wasn't any obvious indication
> >>>> (although there was a release note for keystone [1]) this was wrong
> >>>> or no longer required. The Horizon default was eventually updated to
> >>>> match in this commit to horizon (included in Icehouse and backported
> >>>> to Havana):
> >>>>
> >>>> commit 0aacc44f324c3db049f912da1f84d93c1142cb37
> >>>> Author: JiaHao Li <kaho_lai at hotmail.com>
> >>>> Date:   Thu Dec 26 15:37:14 2013 +0800
> >>>>
> >>>>      Sync OPENSTACK_KEYSTONE_DEFAULT_ROLE with keystone
> >>>>
> >>>>      For now, keystone default role is _member_, while horizon set
> >>>>      OPENSTACK_KEYSTONE_DEFAULT_ROLE to Member. It will really be user
> >>>>      friendly to modify horizon default value to _member_ to sync with
> >>>>      keystone's default setting.
> >>>>
> >>>>      Change-Id: I55d15e6cfb74e52e933c5a44efd6c27930415738
> >>>>      Closes-Bug: #1264228
> >>>>
> >>>> The end result is many older environments still have both roles
> >>>> unless action is taken to manually remove the "Member" one and
> >>>> update the Horizon default to the new value, and I should note it
> >>>> probably wouldn't even be that surprising if there are still some
> >>>> deployment tools creating *new* environments and using a "Member"
> >>>> role - setting horizon to match - in this fashion instead of the
> >>>> "_member_" built-in.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Steve
> >>>>
> >>>> [1] https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Upgrade_Notes_5
> >>>>
> >>> The current situation for users of DevStack is that both _member_ and
> >>> Member are created, and through the Horizon UI users see both and are not
> >>> sure why there are two nor which to use.
> >>>
> >>> :-(
> >>> Mike
> >> This would be an example of "it probably wouldn't even be that surprising
> >> if
> >> there are still some deployment tools creating *new* environments and
> >> using
> >> a "Member"" :). Looking at lib/keystone:
> >>
> >> 318     # The Member role is used by Horizon and Swift so we need to keep
> >> it:
> >> 319     MEMBER_ROLE=$(openstack role create \
> >> 320         Member \
> >> 321         | grep " id " | get_field 2)
> >>
> >> As I outlined above, this means you get two roles because the Keystone SQL
> >> will always create "_member_". The comment mentions that Horizon and Swift
> >> require this, as I outlined above this is no longer true for Horizon - not
> >> sure about Swift.
> >>
> >> -Steve
> > I looked into this and there doesn't appear to be any dependency on
> > _member_  Vs Member in Swift itself, but rather devstack itself introduces
> > such a dependency in the way it sets up and configures swift when it sets
> > the value "Member,admin" for operator_roles. Will file a bug and hopefully
> > a patch shortly.
> 
> THe _member_ role can changed to Member:  there is a config value in
> Keystone.conf for that.

If I understand correctly, that means that Member will be treated as _member_ is, and automatically added to the user/tenant association right? That would still require updates to DevStack/Tempest as they will continue to explicitly add the role to each user, getting a clash because it's already there (currently they don't get this because Keystone is automatically adding _member_ but they are using Member).

This same problem exists if you simply change DevStack to use _member_ of course so in either case, to eliminate the situation where it's creating two distinct member roles it appears that it's necessary to make some updates to at least DevStack and Tempest. I raised a bug here:

    https://bugs.launchpad.net/tempest/+bug/1330132

Thanks,

Steve