Thanks Henry for putting it all together. In my opinion we should go with option "a" (role-assignment as a first class citizen) which seems correct to me, looking in to time constraint, option 'b' is OK as an EXTENSION but SHOULD NOT BE implemented as part of core API.
Thoughts??? Arvind -----Original Message----- From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Monday, June 17, 2013 6:52 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [keystone] Inherited domain roles: Options for Havana and beyond Hi I have amended the etherpad to summarize the two proposed paths: a) Full "role-assignment as a first class entity" for Havana b) Stepping stone approach, for Havana and "I" So you can see what is involved in b), I have amended the two in-flight bp identity proposals to match what this would look like: https://review.openstack.org/#/c/29781/14 https://review.openstack.org/#/c/32394/7 [Ok, technically I should have done this is 3 bp, one for changing the current apis, one for the new GET /role-assignment api (that supports groups but not inherited roles) and then an updated GET /role-assigment api that now supports the inherited roles as well, and would be dependant on the other two bps.....but in the interests of time I kept it simple.] We need to make a call on whether we take a) or b) at tomorrows keystone IRC meeting, if not before. We are running out of time. Henry _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
