----- Original Message ----- > From: "Mike Spreitzer" <mspre...@us.ibm.com> > To: "Steve Gordon" <sgor...@redhat.com> > > Steve Gordon <sgor...@redhat.com> wrote on 06/14/2014 03:22:51 PM: > > > > From: "Mike Spreitzer" <mspre...@us.ibm.com> > > > To: "Steve Gordon" <sgor...@redhat.com> > > > > > > Steve Gordon <sgor...@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_...@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 _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
