Open Stack

Hi

So discussion has been raging on the etherpad () on this topic following the IRC discussion.  Due to the depth of discussion, this pad is now quite long.  I think we do have a couple of potential ways forward:

1) The general consensus is that ideally we should move to a new api for role assignments, including treating a role assignment as first class entity (with a typical v3 style CRUD api).  Although there was still differing views on how "scope" should be defined, we settled on going forward with Option F (which is really the same as Option E, but with an "inheritance" model of scope, rather than an "expression" model).  The challenge with this is that this would be a fairly big change (really have to re-write all our grant tables underneath, provide the new api, and allow intermix with the old apis, fix all the corner cases we haven't thought of yet, etc.).  Given we are a month away from m2, a number of people have concerns as to whether we can achieve this in the time frame.

2) A stepping stone approach is suggested in Option G, where, for Havana, we:
- Use the new api JUST for listing complete role assignments (a bit like the current proposal of https://review.openstack.org/#/c/32394/), but use the new role-assignment entity as the format to the data (less an role_assignment_id).  Links would point a the old assignment api format for how you would change the entities
- Extend the old assignment apis to just allow you to inherit roles to projects of a domain, buy adding the /inherited_to_projects term to the urls, e.g.:
PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects
...and the same for GET, HEAD, DELETE.
- For the next release, we commit to move to provide full support for the new role-assignment entity and api, and depreciate (but still support) the old apis.  The only change to the format returned by GET /role-assignments would be the inclusion of a role_assignment_id and the links would now point to the new api.

Thoughts?

Henry