As worded this is incorrect. In keystone an 'admin' is what we call a 'cloud admin' and what in keystone is called a 'member' is almost but not quite what we call a 'project admin'. I will articulate the full mapping in a future comment.

Largely for my future reference, here's a long discussion with a Horizon dev about how this will work for us:

https://phabricator.wikimedia.org/P368

In Labs:

User: can view project info and access project instances. Cannot change project membership or create VMs.

ProjectAdmin: Everything a User does, plus: can create/delete VMs, modify project membership, and add/delete new ProjectAdmins.

CloudAdmin: Can create/delete projects and modify membership of projects. Can, by adding self to a project, attain other rights of a project admin.

In Keystone/Horizon:

Member: Can create/delete VMs. Can add/remove keypairs for VMs (maybe). Cannot modify project membership in any way.

Admin: Can create/delete projects, can modify membership of projects.

In Keystone/Horizon, some day in the future (possible Kilo, likely L):

Domain Admin/possible-to-be-named-later-role: Can modify membership of a predetermined set of projects.

Is that a statement of fact or just the status quo for Horizon? :-) Having users of the Tools project create and delete VMs would change … everything :-).

Statement of fact. We need to continue to have a concept of a 'user' who can't create/destroy instances, that'll be done in ldap without any real keystone integration.

The hard part is that with Horizon/Keystone, 'members' (who are called projectadmins now) can't add/remove members to a project.