Title: Creating a Member Role Describe the issue: The member role is actually created in the keystone by default as "_member_", it does not need explicit creation. The correct action to take is to ensure that the users created in the Keystone chapter are added to the "_member_" role. In Icehouse the dashboard will also correctly look for the "_member_" role instead of "Member". Suggestions for improvement: +Remove this section. +Ensure keystone sections adds "_member_" role to users as they are created (admin and normal user account if one is created).
This bug is being assigned to Bruce Reeler, who is now the designated docs specialist for keystone.
Bruce, any plans for this? The fact that we go out of our way to manually: - Create a Member role - Add it to every user - Configure Horizon to use it Is really confusing as none of this is required any more. The _member_ role is created automatically, assigned to every user, and is the default for Horizon.
A) Converted section 10.5.3 "Create a Member Role" (Topic ID 15951) into "Change Dashboard's default role" as follows: A1) Mentioned that Dashboard uses default _member_ role, but left in steps to create a new role in case users wish to. A2) Formatted the original Note about changing Dashboard's default role into a final step in the procedure. B) Edited "Procedure 3.10. Creating a regular user account" in section "3.9. Create a Regular User Account" as follows: B1) noted that Identity has a default role called _member_ B2) removed step 3 which was also, like section 10.5.3 in (A) above, creating a Member role. B3) changed step 4 (using the command "keystone user-role-add") to associate the created user and tenant with _member_ role.
(In reply to Bruce Reeler from comment #4) > B) Edited "Procedure 3.10. Creating a regular user account" in section > "3.9. Create a Regular User Account" as follows: > > B1) noted that Identity has a default role called _member_ > B2) removed step 3 which was also, like section 10.5.3 in (A) above, > creating a Member role. > B3) changed step 4 (using the command "keystone user-role-add") to associate > the created user and tenant with _member_ role. Did you actually test B3? As I understand it Keystone creates the role link automatically for the user/tenant combination and subsequent attempts to add it manually will fail.
Moving back to 'NEW' until reassignment.
Assigning to Radek for review. Radek, most of the changes required for this bug have now been implemented, but we need to check if the command in B3 in comment #4 works. This will involve - 1. Checking that a default role '_member_' is created in Keystone. 2. Checking whether the command works, and removing it if it fails or is not required. These changes need to be made in doc-Deploying_OpenStack_Learning_Environments_Manual_Setup in the RHEL-OSP documentation repository. Kind regards, Andrew
I have users admin and test, and tenants admin and tenattest. These were all created by the commends used in the book. However, I don't seem to have the _member_ role, though: [root@localhost ~(keystone_admin)]# keystone role-list WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored). +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | d1baee7c6a2e4ac888cf1680cadbe5ab | admin | +----------------------------------+-------+ Consequently, I believe, I get the following error when I follow step 4 in procedure 3.11: No role with a name or ID of '_member_' exists. Stephen, could you please help me determine what's wrong here? If you want, I can give you the root password to my test box.
I'd still welcome some information regarding the problem described in the previous comment. Still, if packstack --allinone is used to set up the OSP environment, the _member_ role does get created automatically, and when I follow "B3", no failure occurs.
(In reply to Radek Bíba from comment #11) > I'd still welcome some information regarding the problem described in the > previous comment. Still, if packstack --allinone is used to set up the OSP > environment, the _member_ role does get created automatically, and when I > follow "B3", no failure occurs. I believe the default behaviour around this may have changed yet again. To ascertain exactly what happened in the manual case would need the output of: 1) keystone role-list 2) keystone user-role-list admin 3) grep member_role_ /etc/keystone/keystone.conf
Note: Using a different machine but the same setup. (In reply to Stephen Gordon from comment #12) > 1) keystone role-list +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | 411832b554c5409798a5640cf22b07a0 | admin | +----------------------------------+-------+ > 2) keystone user-role-list admin usage: keystone [--version] [--debug] [--os-username <auth-user-name>] ... keystone: error: unrecognized arguments: admin Perhaps you meant something like: [root@sheep-3 ~]# keystone user-role-list --user admin --tenant admin +----------------------------------+-------+----------------------------------+----------------------------------+ | id | name | user_id | tenant_id | +----------------------------------+-------+----------------------------------+----------------------------------+ | 411832b554c5409798a5640cf22b07a0 | admin | c3f2137da87947a6a3d0c38b3b4f85c8 | 714dc617f47549b8888c98f98c09caad | +----------------------------------+-------+----------------------------------+----------------------------------+ > 3) grep member_role_ /etc/keystone/keystone.conf # During a SQL upgrade member_role_id will be used to create a # member_role_id will be used in the API add_user_to_project. #member_role_id=9fe2ff9ee4384b1894a90878d3e92bab # During a SQL upgrade member_role_name will be used to create # with explicit role grants. After migration, member_role_name #member_role_name=_member_
Hi Radek, One more for the road - please provide the output of `keystone role-list`. What I am trying to confirm is the ID of the _member_ role in your system and that the admin user is actually in it.
Hi Stephen, The output of keystone role-list is already in comment 13: +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | 411832b554c5409798a5640cf22b07a0 | admin | +----------------------------------+-------+ This time, from yet another test box configured the same way, it's not much different: # keystone role-list +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | 3c7859248b054583925e1a5176447c61 | admin | +----------------------------------+-------+ And again: # keystone user-role-add --user USER --role _member_ --tenant TENANT No role with a name or ID of '_member_' exists.
Some more updates: According to http://docs.openstack.org/juno/install-guide/install/yum/content/keystone-users.html, the _member_ role gets created automatically when the --tenant option is used while creating a user. And this is what I see when I remove USER (originally created by "keystone user-create --name USER --pass PASSWORD") and recreate it with --tenant: # keystone role-list +----------------------------------+-------+ | id | name | +----------------------------------+-------+ | 3c7859248b054583925e1a5176447c61 | admin | +----------------------------------+-------+ # keystone user-delete USER # keystone user-create --name USER --tenant TENANT --pass PASSWORD +----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | | | enabled | True | | id | 56910f2928024ede8d5484c3fffcc49a | | name | USER | | tenantId | 2587d813623a44ab9605bb09751a009a | | username | USER | +----------+----------------------------------+ # keystone role-list +----------------------------------+----------+ | id | name | +----------------------------------+----------+ | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | 3c7859248b054583925e1a5176447c61 | admin | +----------------------------------+----------+ So I think steps 2 and 3 in procedure 3.10 need these tweaks.
(In reply to Radek Bíba from comment #16) > Some more updates: > > According to > http://docs.openstack.org/juno/install-guide/install/yum/content/keystone- > users.html, the _member_ role gets created automatically when the --tenant > option is used while creating a user. And this is what I see when I remove > USER (originally created by "keystone user-create --name USER --pass > PASSWORD") and recreate it with --tenant: > > # keystone role-list > +----------------------------------+-------+ > | id | name | > +----------------------------------+-------+ > | 3c7859248b054583925e1a5176447c61 | admin | > +----------------------------------+-------+ > # keystone user-delete USER > # keystone user-create --name USER --tenant TENANT --pass PASSWORD > +----------+----------------------------------+ > | Property | Value | > +----------+----------------------------------+ > | email | | > | enabled | True | > | id | 56910f2928024ede8d5484c3fffcc49a | > | name | USER | > | tenantId | 2587d813623a44ab9605bb09751a009a | > | username | USER | > +----------+----------------------------------+ > # keystone role-list > +----------------------------------+----------+ > | id | name | > +----------------------------------+----------+ > | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | > | 3c7859248b054583925e1a5176447c61 | admin | > +----------------------------------+----------+ > > So I think steps 2 and 3 in procedure 3.10 need these tweaks. Right that makes sense, if you aren't associating them with a tenant then they aren't a member. Looks good.
Looks good to me; merging.
This content is now live on the Customer Portal. Closing.