On 06/14/2014 05:59 PM, Steve Gordon wrote:
----- Original Message -----
From: "Steve Gordon" <sgor...@redhat.com>
To: "Mike Spreitzer" <mspre...@us.ibm.com>
----- 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
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.
-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
_______________________________________________
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
