Open Stack

David/Kristy,

So let's try and move this discussion on so that we at least have a clearer description of what we would implement on both paths - and make progress towards getting code into Grizzly.

The traditional implementation (as defined by the bp: https://blueprints.launchpad.net/keystone/+spec/user-groups ) would involve:
- Api implementation to support semantics described (e.g. in keystone client)
- A GroupControllerV3 in keystone to pick up and dispatch these calls to the backends (e.g sql, kvs), as well as a few changes to other controllers affected (e.g. RoleController)
- Backend implementations to support the semantics - e.g. in sql the addition of a group,  GroupProjectMetadata and GroupDomainMetadata tables, mirroring the way we do user-project/domain-role assignment
- Tests at the various levels against all these

Now I *think* what you are suggesting is that, if we were instead to use attributes to achieve group membership, that the code in the Controllers would instead make calls to the attribute mapping service for group membership aspects.  It isn't really a new backend (since you aren't supporting everything as attributes), but conceptually something similar.  Do I have that right?  Or do you see the changes as more pervasive?

Given that I am implementing this starting from the front end (e.g. create the api support fist and all the tests should all fail with not implemented), then the controllers, and then backends...this might interlock with a little more time to make a decision on where the backend is implemented.  Given the rather nice clean way that the new controllers/backends are implemented - even doing a reference implementation in the traditional fashion, then swapping out (or modifying) the controllers to talk to the attribute mappings service might be a good way of progressing this.

Henry