<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Henry,<div><br></div><div>I've added the proposed API changes for our role mapping service to the role mapping blueprint specification (<a href="https://blueprints.launchpad.net/keystone/+spec/role-mapping-service-keystone">https://blueprints.launchpad.net/keystone/+spec/role-mapping-service-keystone</a>) which should hopefully clarify some things. </div><div><br></div><div>Kristy</div><div><br></div><div><br><div><div>On 10 Dec 2012, at 10:23, David Chadwick wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Henry<br><br>if the GUI uses the MVC pattern then surely the GUI issue is largely<br>irrelevant isnt it, since the user view can be of either groups or mappings.<br><br>> So in terms of customer experience, I think you are saying that if a<br>> cloud provider wants to offer organizational roles to their<br>> customers, then there is a manual set up required by the Keystone<br>> admin to create these sets<br><br>Yes in the first release. Though we have discussed an automated set up where the keystone admin creates a config file and the set up is done automatically from this by a tool that calls the APIs.<br><br><br>...these, I assume, are in addition to the<br>> user/roles/metadata tables (or whichever backend solution is bring<br>> used) that  will exist already?<br><br>Yes, these also have to be set up manually or via a set of tools<br><br>>  We'll need to come up with a way of<br>> sharing the names/Ids of these"well known"  sets - since keystone<br>> will need to name them in the api calls to pick up the mappings.<br><br>I dont think that knowing the names of the sets needs to be known by anyone except the keystone admin since he is the only one who will see them. He will need to know the names of the org attributes and the org admin will need to know the names of the roles. The sets are an internal grouping mechanism that dont need to be externally visible in the first release.<br><br>Depending upon how the access controls are set up in the second release, the set names may need to be known by the org admins.<br><br>> we need to<br>> allow organizational roles to be assigned to a domain or a project<br>> (and hence and user who has that organizational attribute then gets<br>> the respective role on that object)<br><br>The concept is the same. Domain will simply become another internal attribute that the external org attributes can map into<br><br>regards<br><br>David<br><br>On 10/12/2012 09:49, Henry Nash wrote:<br><blockquote type="cite">Hi<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So a few additional comments in-line below.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Further, I'd like to (re-)suggest my original proposal that we submit<br></blockquote><blockquote type="cite">a reference implementation for groups as defined in the blueprint (in<br></blockquote><blockquote type="cite">fact the client side api for this is already up for review at:<br></blockquote><blockquote type="cite"><a href="https://review.openstack.org/#/c/17693/">https://review.openstack.org/#/c/17693/</a>).  The server side would be<br></blockquote><blockquote type="cite">available for review this week - this is relatively straight forward<br></blockquote><blockquote type="cite">given the existing rather nice design of the v3 support in general<br></blockquote><blockquote type="cite">(kudos to whoever did that, btw).  The advantage of this approach is<br></blockquote><blockquote type="cite">that<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">a) We are guaranteed a solution for Grizzly b) As components of the<br></blockquote><blockquote type="cite">attribute mapping service come into play, we integrate them in to the<br></blockquote><blockquote type="cite">exiting flow and remove redundant parts of the reference<br></blockquote><blockquote type="cite">implementation c) We can decide fairly late how pervasive the<br></blockquote><blockquote type="cite">attribute support for organizational roles  is - e.g. - if it<br></blockquote><blockquote type="cite">front-ended by a more traditional simple groups api?  Or an attribute<br></blockquote><blockquote type="cite">api, with a simpler "groups" ui, or the full thing, etc.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This would give us a lot of flexibility - e.g. we could decide, for<br></blockquote><blockquote type="cite">instance, that in Grizzly, we'll use the attribute mapper to store<br></blockquote><blockquote type="cite">the group relationship, but actually present it as a traditional<br></blockquote><blockquote type="cite">group capability on the front end (i.e. give us more time to come up<br></blockquote><blockquote type="cite">with a suitable api/ui for generalized attribute mapping...maybe with<br></blockquote><blockquote type="cite">a preview in Grizzly)...and then expose the (already stored in AM)<br></blockquote><blockquote type="cite">underlying relationships directly in H.   Or some other combination<br></blockquote><blockquote type="cite">of hybrid implementation that lets us strike that right balance for<br></blockquote><blockquote type="cite">the state of the s/w in a couple of months.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Adam/Dolph - any views/comments?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Henry On 7 Dec 2012, at 15:05, David Chadwick wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Henry<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 07/12/2012 14:24, Henry Nash wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi David/Kirtsy,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So a few questions:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- How do the attribute sets get created (e.g. roles, projects,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">domains)?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In the first version the Keystone admin will create them via a new<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">user command. We dont think the backend storage will need altering<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as we are simply creating a new type of object to be stored there.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(An organisation admin could also create new mappings but it would<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be uncontrolled access). In the second version organisational<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">admins will create the mappings and access controls will ensure<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">they can only set their own attributes to authorised roles. So we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">can have multiple administrators updating different mappings in a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">controlled manner in the second version.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">So in terms of customer experience, I think you are saying that if a<br></blockquote><blockquote type="cite">cloud provider wants to offer organizational roles to their<br></blockquote><blockquote type="cite">customers, then there is a manual set up required by the Keystone<br></blockquote><blockquote type="cite">admin to create these sets...these, I assume, are in addition to the<br></blockquote><blockquote type="cite">user/roles/metadata tables (or whichever backend solution is bring<br></blockquote><blockquote type="cite">used) that  will exist already?  We'll need to come up with a way of<br></blockquote><blockquote type="cite">sharing the names/Ids of these"well known"  sets - since keystone<br></blockquote><blockquote type="cite">will need to name them in the api calls to pick up the mappings.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Are you assuming that as these are created in keystone<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">they are replicated into the attribute service?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">No, they are stored in Keystone's backend storage and the AM reads<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">then from there. So they are only stored once.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Or that these are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">created independently somehow? Or maybe crated on-the-fly as<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">relationship requests come in?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Yes to both. Independently created by admin during initial<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">configuration of Keystone. Then they will also be created on the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fly in the federated Keystone when new users appear. The way this<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">will work is as follows i) the mapping that the admin puts in says<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this attribute type (but no value specified) maps into a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">tenant/project with no value specified. ie. it is a rule for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">creating new tenants for each new identified user who has a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">specific set of attributes. (the same can apply for roles, although<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that sort of defeats the whole purpose of RBAC if each user has his<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">own role. However it could be done at the organisation level e.g.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">set up a mapping for org attribute to role, then every new<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">organisation would create a new role for itself and every user from<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the organisation would get the new role)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ii) When a federated user first uses Keystone, the federated module<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">will find that no specific mapping exists for him so it will create<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a new tenant and or role and add a new mapping for this user to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this tenant/role using the AM.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- What api (that other projects can<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">use) actually populates the mapping service with the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">group-project-role and group-domain-role relationships<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Kristy has already specified the API internally. She should publish<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it over the weekend or on Monday.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(remember<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there are no "tenants" in v3)?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tenants are projects arent they? So doesnt v3 have projects? If so<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">we can simply substitute tenant for project.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Yes there are projects, but projects are not the only thing that can<br></blockquote><blockquote type="cite">have roles assigned to - so can Domains.  Large enterprise customers<br></blockquote><blockquote type="cite">will  probably treat the domain as the "account holder" or tenant,<br></blockquote><blockquote type="cite">not the projects that come and go. So in this scenario we need to<br></blockquote><blockquote type="cite">allow organizational roles to be assigned to a domain or a project<br></blockquote><blockquote type="cite">(and hence and user who has that organizational attribute then gets<br></blockquote><blockquote type="cite">the respective role on that object)<br></blockquote><blockquote type="cite"><blockquote type="cite">Is this front-end api the one I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">defined in the user-groups blueprint,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Not sure we will need to check this out<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">but that the backend<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">relationships for groups are then stored in the attribute<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">service?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the AM does not store anything itself. It relies on Keystone's<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">existing storage mechanism to store the objects. What the AM does<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is define some new objects and populate the Keystone storage with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">them. So we have defined add, read and delete operations on these<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">objects.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Or<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">are you thinking that the other projects will call the mapping<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">service to define those relationships?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In principle any administrator can use the AM API to create<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">mappings, but in order to activate and control this, we will need a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">proper access control mechanism with delegation of authority from<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the Keystone administrator to the AM administrators. This<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">delegation might be by the keystone admin creating access rules<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">himself for these other AM administrators e.g. by creating some new<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">admin roles and then assigning these roles to the other AM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">administrators. Precise details are still to be worked out for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If the later, have we defined<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">this api (in terms of what actual http calls we support and the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">client side python to make it easy for these to called)?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that's good. So Kristy should compare your APIs with her APIs and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">see what the similarities and differences are. Can I leave it to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the two of you to agree what these APIs should be. Essentially we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">need get, post and delete<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">Sure.  More than this, however, have we thought about what an example<br></blockquote><blockquote type="cite">UI would be for this - we will need that in Horizon.  We want people<br></blockquote><blockquote type="cite">to have organziational roles out of the box.  This might be<br></blockquote><blockquote type="cite">challenging - we need to come up with a generalized UI concept for<br></blockquote><blockquote type="cite">attribute mapping (I assume there must be examples of this already,<br></blockquote><blockquote type="cite">however), that is simple enough not to confuse the users who just<br></blockquote><blockquote type="cite">want "groups" when there are in, what is for now, the usual case of a<br></blockquote><blockquote type="cite">non-federated world, but is extensible enough not to require<br></blockquote><blockquote type="cite">re-design if they ever go federated.<br></blockquote><blockquote type="cite"><blockquote type="cite">regards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">David<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Henry On 6 Dec 2012, at 13:46, David Chadwick wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi Henry<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I discussed this very topic with Dolph in London yesterday.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This is what we agreed would be the most sensible<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">implementation route (Dolph please correct me if I am wrong)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1. Henry writes code that can add group memberships to the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">user identity store (maybe backend LDAP or whatever). Each user<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">will probably have a group member attribute added to his entry,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">but details are for Henry to decide, since he will be<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">responsible for both storing and picking up the groups. This<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">will probably involve changes to Keystone client, but may not<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">require any changes to the backend storage, depending upon how<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">flexible it is (e.g. Kristy has managed to add IDPs to the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">service catalog without making any changes to the service<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">catalog or backend storage)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2. Henry writes a new Keystone middleware module for the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">pipeline that, after the user has been identified and<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">authenticated, calls the identity store to pick up the user's<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">groups (added in 1 above). It then calls Kristy's Attribute<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Mapping Service, passing it the groups and getting back the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">tenants and roles. It then hands back control to the Keystone<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">pipeline.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">regards<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">David<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 06/12/2012 11:43, Henry Nash wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">David/Kristy,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So let's try and move this discussion on so that we at least<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">have a clearer description of what we would implement on both<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">paths - and make progress towards getting code into Grizzly.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The traditional implementation (as defined by the bp:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="https://blueprints.launchpad.net/keystone/+spec/user-groups">https://blueprints.launchpad.net/keystone/+spec/user-groups</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">) would involve: - Api implementation to support semantics<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">described (e.g. in keystone client) - A GroupControllerV3 in<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">keystone to pick up and dispatch these calls to the backends<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(e.g sql, kvs), as well as a few changes to other controllers<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">affected (e.g. RoleController) - Backend implementations to<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">support the semantics - e.g. in sql the addition of a group,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">GroupProjectMetadata and GroupDomainMetadata tables,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mirroring the way we do user-project/domain-role assignment -<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Tests at the various levels against all these<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Now I *think* what you are suggesting is that, if we were<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">instead to use attributes to achieve group membership, that<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the code in the Controllers would instead make calls to the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">attribute mapping service for group membership aspects.  It<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">isn't really a new backend (since you aren't supporting<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">everything as attributes), but conceptually something<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">similar.  Do I have that right?  Or do you see the changes as<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">more pervasive?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Given that I am implementing this starting from the front<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">end (e.g. create the api support fist and all the tests<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">should all fail with not implemented), then the controllers,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and then backends...this might interlock with a little more<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">time to make a decision on where the backend is implemented.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Given the rather nice clean way that the new<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">controllers/backends are implemented - even doing a reference<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">implementation in the traditional fashion, then swapping out<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(or modifying) the controllers to talk to the attribute<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mappings service might be a good way of progressing this.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Henry<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div></blockquote></div><br></div></body></html>