Comment 3 for bug 1403136

I think I understand why the manual specifies that the deployer should "create the _member_" role using "keystone role-create --name _member_" (to support the explicit assignment in the following step), but I'd recommend removing that instruction as a starting point to addressing this issue. I'm not sure what to do about the following step that utilizes the _member_ role, though, other than avoid using _member_ (in that specific case, the admin user is being assigned a _member_ role on the admin tenant ... whereas this would normally only be an "admin" role assignment and you're done).

Background: keystone actually creates this role for you automatically, as needed, to provide backwards compatibility for v2 calls wherein default tenancy is used. The gist is that we want authorization assignments to be an explicit triplet in v3. For example user + project + role. v2's notion of default tenancy means that no specific role is involved, so Keystone creates the _member_ role if it doesn't already exist, so that the assignment can be explicit. Keystone has a pre-conceived member_role_name and member_role_id in keystone.conf that is used whenever the _member_ role comes into play.

The behavior described in the report is then accurate: the "_member_ " role is successfully created manually, but when it's used by user-create with default tenancy, the member_role_id in keystone.conf does not match _member_'s ID in the backend (so it's not found), and thus Keystone tries to create the role again, resulting in a 409 Conflict (duplicate role name: _member_).

It might be possible for Keystone to avoiding putting you in this scenario by having Keystone notice the role you're trying to create, and then at least ensuring that's its created as defined in keystone.conf. So I'm going to add Keystone here as well.