To clarify steps 1 & 2, I read this as two *different* relationships being created between User B and Project B.
First, User B is created with a default tenant of Project B. <-- This behaves as expected.
Second, User B is explicitly granted the admin role on Project B. <-- This take effect globally, regardless.
In terms of the keystone CLI, this looks like:
keystone tenant-create --name=project-b
keystone user-create --name=user-b --pass=secret --tenant_id=<tenant id of project b>
keystone user-role-add --user=<user id of user b> --role=<role id of admin role> --tenant_id=<tenant id of project b>
After creating User B, I then confirmed the bug by authenticating as User B for Project B, and then successfully listing all users and tenants in the system, and then subsequently deleting User A and Project A.
To clarify steps 1 & 2, I read this as two *different* relationships being created between User B and Project B.
First, User B is created with a default tenant of Project B. <-- This behaves as expected.
Second, User B is explicitly granted the admin role on Project B. <-- This take effect globally, regardless.
In terms of the keystone CLI, this looks like:
keystone tenant-create --name=project-b
keystone user-create --name=user-b --pass=secret --tenant_id=<tenant id of project b>
keystone user-role-add --user=<user id of user b> --role=<role id of admin role> --tenant_id=<tenant id of project b>
After creating User B, I then confirmed the bug by authenticating as User B for Project B, and then successfully listing all users and tenants in the system, and then subsequently deleting User A and Project A.