Open Stack

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.

>
> -Steve
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack