Open Stack

----- 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