Open Stack

This is a bit different from how I would have expected it to work. It appears that you are adding the role assignment when the project is created. IMO the role should be added to the list when the roles are checked. In other words, when getting the list of roles for a user/project, it walks up the tree to find all parent projects and creates a list of roles that includes all of the parent roles for that user that are marked inheritable. The implementation you made seems very fragile if parent projects are changed etc.

Vish

On Apr 14, 2014, at 12:17 PM, Raildo Mascena <raildom at gmail.com> wrote:

> Hi all,
> 
> As I had promised, here is the repository of Telles Nobrega (https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now with inherited roles working with hierarchical projects.
> 
> How ​does ​it work​​?
> 
> ​I​nherited roles operate in the following way:
> - It should be added​ a role ​to​ be inherited to a domain using the api "PUT localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects".
> - It should be create​d​ a hierarchical project as described above for Telles.
> - List the assignments roles "GET localhost: 35357/v3/role_assignments"  and check that the role inherited is already associated with this new project. 
> 
> What was implemented? 
> The implementation consists of filter​ing​ roles which are associated with the parent project to be inherited (this is done by checking the assigment table) for them to be added to the child project. Also a filter has been created to ensure that a role inherited from another domain does not interfere in the inheritance of this project.
> 
> What remains to implement?
> 
> Role inherit​ance​ has been implemented to work with domains, so the role will be inherited to all projects contained this domain, ie, a role that is marked to be inherited, even if it is not associated with the parent project, will be inherited to the child project. In my opinion, should ​be ​create​d​ a "project" column in the "assignment" that would indicate where to start inheritance projects, it would be possible to finish this feature. (This is just a suggestion, I believe ​there are other ways to make it work).
> 
> 
> 2014-03-17 8:04 GMT-03:00 Telles Nobrega <tellesnobrega at gmail.com>:
> That is good news, I can have both information sent to nova really easy. I just need to add a field into the token, or more than one if needed. RIght now I send Ids, it could names just as easily and we can add a new field so we can have both information sent. I'm not sure which is the best option for us but i would think that sending both for now would keep the compatibility and we could still use the names for display porpuse 
> 
> 
> On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
> > Awesome, this is exactly what I was thinking. I think this is really
> > close to being usable on the nova side. First of all the
> > dot.sperated.form looks better imo, and I think my code should still
> > work that way as well. The other piece that is needed is mapping ids
> > to names for display purposes. I did something like this for a
> > prototype of names in dns caching that should work nicely. The
> > question simply becomes how do we expose those names. I’m thinking we
> > have to add an output field to the display of objects in the system
> > showing the fully qualified name.  We can then switch the display in
> > novaclient to show names instead of ids.  That way an admin listing
> > all the projects in orga would see the owner as orga.projb instead of
> > the id string.
> >
> > The other option would be to pass names instead of ids from keystone
> > and store those instead. That seems simpler at first glance, it is not
> > backwards compatible with the current model so it will be painful for
> > providers to switch.
> 
> -1 for "instead of". "in addition to" would have been fine, IMO.
> 
> Best,
> -jay
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> ------------------------------------------
> Telles Mota Vidal Nobrega
> Bsc in Computer Science at UFCG
> Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Raildo Mascena
> Bachelor of Computer Science. 
> Software Engineer at Laboratory of Distributed Systems - UFCG
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/f287bcb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/f287bcb8/attachment.pgp>