[openstack-dev] [keystone] Inherited domain roles: Options for Havana and beyond

Henry Nash henryn at linux.vnet.ibm.com
Mon Jun 17 22:51:03 UTC 2013


Hi

So I am also convinced by option a)....it is just the time frame.  I would be happy to commit to completing this for Havana m3 - but we all agreed that any significant api-changing modifications would be in and stable by m2....and that feels like a much taller order. e.g. we need to:

- Create the new entity backend storage (and decide how we map it in the various backend technologies, e.g. LDAP)
- Re-implment the existing v3 apis on top of it
- Implement the new role-assignmetn apis on top of it
- Provide DB migration up and down
- Test the hell out of it, especially the intermixing of new and old apis.

My gut feel is we would have to get agreement that we would bring this support in fully at m3 (maybe partial at m2) for us to commit to option a) for Havana.

Henry

On 17 Jun 2013, at 18:33, Tiwari, Arvind wrote:

> 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:henryn at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list