Bug 984294

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.

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.

Created attachment 832341 [details]
screenshot of _member_ value

I did reproduce this problem with current packstack

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,
                 keystone.exception.UserNotFound

        """
        try:
            self.driver.add_role_to_user_and_project(
                user_id,
                tenant_id,
                config.CONF.member_role_id)
---

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 

---
``OPENSTACK_KEYSTONE_DEFAULT_ROLE``
-----------------------------------

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

Adam, could you please give us a hand here?

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

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

---
add_user_to_project:

        except exception.RoleNotFound:
            LOG.info(_("Creating the default role %s "
                       "because it does not exist."),
                     config.CONF.member_role_id)
            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
            self.driver.add_role_to_user_and_project(
                user_id,
                tenant_id,
                config.CONF.member_role_id)
---

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

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?

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

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

That makes sense to me.

Created attachment 833518 [details]
screenshot of no duplicate member roles

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

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?

(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?

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.

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

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.

can i have QE ack for this bug?