Bug 984294 - horizon: edit project has _member_ and Member values
horizon: edit project has _member_ and Member values
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack (Show other bugs)
x86_64 Linux
low Severity low
: z6
: 5.0 (RHEL 7)
Assigned To: Ian Wienand
: Triaged, ZStream
Depends On:
  Show dependency treegraph
Reported: 2013-07-14 10:36 EDT by Dafna Ron
Modified: 2016-05-12 09:41 EDT (History)
17 users (show)

See Also:
Fixed In Version: openstack-packstack-2014.2-0.17.dev1462.gbb05296.el7ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-12 09:41:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot of _member_ value (73.70 KB, image/png)
2013-12-03 20:05 EST, Ian Wienand
no flags Details
screenshot of no duplicate member roles (46.11 KB, image/png)
2013-12-06 05:15 EST, Ian Wienand
no flags Details

  None (edit)
Description Dafna Ron 2013-07-14 10:36:50 EDT
Description of problem:

in project menu, when we press the project member and expand the scroll bar, we have _member_ and Member value. 
if there is a difference in these values than _member_ should get a different name 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. in Admin view go to project 
2. Modify users
3. expend the users scroll bar

Actual results:

we have _member_ value and a Member value

Expected results:

if _member_ has a different meaning than Member we should change the name else we should remove it

Additional info:
Comment 1 Jaroslav Henner 2013-07-15 05:08:11 EDT
Note the release notes: https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly. Search for _member_

I think this is a Packstack problem. It should probably rename _member_ to Member and not crate aditional Member role.
Comment 2 Julie Pichon 2013-07-16 11:20:49 EDT
Roles are created by the admin at installation time or later, and their naming is outside the control of Horizon.

As per Jaroslav's comment #1 I will move this to Packstack to see if they want to look into it. If this wasn't installed using Packstack, please feel free to close or move to the appropriate component.

Note that Horizon needs to know which default role to use with Keystone. This is defined in /etc/openstack-dashboard/local_settings and is set to "Member" by default.
Comment 3 Ian Wienand 2013-12-03 20:05:25 EST
Created attachment 832341 [details]
screenshot of _member_ value

I did reproduce this problem with current packstack
Comment 4 Ian Wienand 2013-12-04 00:22:56 EST
There have been other questions on this like [1] but it doesn't really explain what's going on

On _member_, the upgrade nodes say

Member role: Users with a default tenant_id attribute or any relationship to an existing tenant are granted a new role that is automatically created by keystone-manage db_sync. After this migration, the default tenant_id attribute (v2.0) and default_project_id user attributes no longer grant any actual authorization, and are instead treated as a user-specified preference. The name and ID of the member role are configurable via member_role_id and member_role_name in keystone.conf. The default values (9fe2ff9ee4384b1894a90878d3e92bab and _member_, respectively) are intended to avoid conflicts with existing deployments.

the keystone.conf says

# Role for migrating membership relationships
# During a SQL upgrade, the following values will be used to create a new role
# that will replace records in the user_tenant_membership table with explicit
# role grants.  After migration, the member_role_id will be used in the API
# add_user_to_project, and member_role_name will be ignored.
# member_role_id = 9fe2ff9ee4384b1894a90878d3e92bab
# member_role_name = _member_

Looking at "add_user_to_project" it is

    def add_user_to_project(self, tenant_id, user_id):
        """Add user to a tenant by creating a default role relationship.

        :raises: keystone.exception.ProjectNotFound,


i.e. the way that keystone seems to keep the user->project relationship is via this role, whereas possibly in previous versions it kept a separate table (user_tenant_membership?).  See commit [2]

So, compare that with 


Default: "Member"

The name of the role which will be assigned to a user when added to a project.
This name must correspond to a role name in Keystone.

Is it the case that horizon is keeping track of user->project mappings with "Member" role, and keystone is keeping track with "_member_" role?  Are these roles really the same thing?  i.e. if we rename keystone's "_member_" role won't horizon be modifying the user->role relationships that should be private to keystone (e.g. what if keystone wants to modify how it maps users->projects again...)

[1] https://ask.openstack.org/en/question/4759/member-vs-_member_/
[2] https://github.com/openstack/keystone/commit/b20302aa3e08421295140576d0aeea2fa9e34188
Comment 5 Alvaro Lopez Ortega 2013-12-04 05:54:54 EST
Adam, could you please give us a hand here?
Comment 6 Adam Young 2013-12-04 10:09:33 EST
_member_   and Member can be joined by setting the keystone.conf file value for member_role_id to the ID for Member.  It needs to be explicitly set.
Comment 7 Ian Wienand 2013-12-04 19:01:51 EST
TBH it's still not clear to me how horizon is using OPENSTACK_KEYSTONE_DEFAULT_ROLE of "Member" and keystone is using its default _member_ id and they agree on who is in what project.

But the trick would seem to be to not create the _member_ role at all, because once it is there it will start showing up in the horizon ui

As far as I can tell, "_member_" is created by puppet [1]

I think ordering is important; we need to

1) create the Member role
2) get the id, put in keystone.conf member_role_id
3) restart keystone to pickup config

(or similar) because otherwise keystone will make it's own role when someone is added to a project, and we'll be back to having two "member" roles showing up


        except exception.RoleNotFound:
            LOG.info(_("Creating the default role %s "
                       "because it does not exist."),
            role = {'id': CONF.member_role_id,
                    'name': CONF.member_role_name}
            self.driver.create_role(config.CONF.member_role_id, role)
            #now that default role exists, the add should succeed

The implications for upgrade aren't clear to me.  I *think* it would be ok if the config file had the correct values before sql migrations started

[1] https://github.com/packstack/puppet-keystone/blob/master/manifests/roles/admin.pp#L54
Comment 8 Ian Wienand 2013-12-05 00:33:41 EST
The other suggestion is to change OPENSTACK_KEYSTONE_DEFAULT_ROLE to _member_, to avoid having to modify keystone.conf as described.

I think, however, that will not solve the problem as shown in the screenshot because the _member_ role will still exist, so you'll still see "Member" and "_member_" without any clues as to which is the correct one?
Comment 9 Julie Pichon 2013-12-05 02:28:28 EST
The drop-down in that screenshot only shows the list of roles as it is defined in Keystone. If only "_member_" is created, and the Horizon default role variable is changed to match it, there shouldn't be any need for "Member" (unless it's still created at another point in the installation, although at the moment my guess would that it was only added in order to satisfy the Horizon default).
Comment 10 Ian Wienand 2013-12-05 06:21:12 EST
Ok, thanks Julie for pointing out it's dynamically sourced from keystone.

So we:

1) stop "Member" from being created by keystone::auth at [1]
2) change where we set the default horizon role to _member_ [2]

That leaves us with only _member_

Matthias/Julie sound about right?

[1] https://github.com/packstack/puppet-keystone/blob/master/manifests/roles/admin.pp#L54
[2] https://github.com/packstack/puppet-openstack/blob/master/manifests/horizon.pp#L73
Comment 11 Julie Pichon 2013-12-05 06:29:55 EST
That makes sense to me.
Comment 12 Ian Wienand 2013-12-06 05:15:07 EST
Created attachment 833518 [details]
screenshot of no duplicate member roles
Comment 13 Ian Wienand 2013-12-06 05:20:41 EST
I've sent out two reviews

[1] - make horizon use "_member_"
[2] - don't create "Member" role in keystone

This gives me a role list like [3]

I'll update the packstack submodules when those changes pass reviews

[1] https://review.openstack.org/#/c/60462/
[2] https://review.openstack.org/#/c/60463/
[3] https://bugzilla.redhat.com/attachment.cgi?id=833518
Comment 14 Stephen Gordon 2014-01-10 15:02:45 EST
Dumb question from me, why are we working around this in puppet/packstack instead of checking whether the default value in upstream horizon can/should be changed?

It seems like the fact that Keystone by default creates a _member_ role and Horizon expects Member is a discrepancy that transcends distributions?
Comment 15 Ian Wienand 2014-01-12 21:56:10 EST
(In reply to Stephen Gordon from comment #14)
> It seems like the fact that Keystone by default creates a _member_ role and
> Horizon expects Member is a discrepancy that transcends distributions?

It's the keystone/horizon puppet modules that are creating the roles (see the links in comment#10), not the projects?  or did I misunderstand your question?
Comment 16 Julie Pichon 2014-01-13 04:42:46 EST
FWIW - someone recently proposed what Stephen is suggesting upstream, see https://bugs.launchpad.net/horizon/+bug/1264228 . Even if it merges though, the 2nd review linked in comment #13 is still needed.
Comment 17 Udi 2014-04-29 08:28:44 EDT
As of Havana A4, the foreman installer sets OPENSTACK_KEYSTONE_DEFAULT_ROLE to "_member_", to be in sync with keystone. However the packstack installer still leaves the setting as "Member" so this bug needs to be fixed.

See also the foreman bug: https://bugzilla.redhat.com/show_bug.cgi?id=1085547
Comment 18 Attila Fazekas 2015-03-04 01:52:01 EST
I do not know why keystone defaults to '_member_' name, but those keystone options are added to allow you to keep the already existing Member role, when you are updating from an older system.

IMHO the 'Member' named Role should be preserved and configured everywhere.
Comment 20 Ivan Chavero 2015-12-02 14:47:46 EST
can i have QE ack for this bug?

Note You need to log in before you can comment on or make changes to this bug.