Open Stack

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

-Steve