<div dir="ltr"><div>Hi all,</div><div><br></div><div>As I had promised, here is the repository of Telles Nobrega (<a href="https://github.com/tellesnobrega/keystone/tree/multitenancy">https://github.com/tellesnobrega/keystone/tree/multitenancy</a>) updated now with inherited roles working with hierarchical projects.</div>
<div><br></div><div>How does it work?</div><div><br></div><div>Inherited roles operate in the following way:</div><div>- 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".</div>
<div>- It should be created a hierarchical project as described above for Telles.</div><div>- List the assignments roles "GET localhost: 35357/v3/role_assignments" and check that the role inherited is already associated with this new project. </div>
<div><br></div><div>What was implemented? </div><div>The implementation consists of filtering 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.</div>
<div><br></div><div>What remains to implement?</div><div><br></div><div>Role inheritance 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 created 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).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-17 8:04 GMT-03:00 Telles Nobrega <span dir="ltr"><<a href="mailto:tellesnobrega@gmail.com" target="_blank">tellesnobrega@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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 </div>
</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:<br>
> Awesome, this is exactly what I was thinking. I think this is really<br>
> close to being usable on the nova side. First of all the<br>
> dot.sperated.form looks better imo, and I think my code should still<br>
> work that way as well. The other piece that is needed is mapping ids<br>
> to names for display purposes. I did something like this for a<br>
> prototype of names in dns caching that should work nicely. The<br>
> question simply becomes how do we expose those names. I’m thinking we<br>
> have to add an output field to the display of objects in the system<br>
> showing the fully qualified name. We can then switch the display in<br>
> novaclient to show names instead of ids. That way an admin listing<br>
> all the projects in orga would see the owner as orga.projb instead of<br>
> the id string.<br>
><br>
> The other option would be to pass names instead of ids from keystone<br>
> and store those instead. That seems simpler at first glance, it is not<br>
> backwards compatible with the current model so it will be painful for<br>
> providers to switch.<br>
<br>
</div>-1 for "instead of". "in addition to" would have been fine, IMO.<br>
<br>
Best,<br>
-jay<br>
<div><div><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <br><div dir="ltr">------------------------------------------<br>Telles Mota Vidal Nobrega<div>Bsc in Computer Science at UFCG<br>
Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG</div>
</div>
</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><span style="font-family:arial;font-size:small">Raildo Mascena</span><br style="font-family:arial;font-size:small"><div style="font-family:arial;font-size:small">
<div dir="ltr">Bachelor of Computer Science. </div><div dir="ltr">Software Engineer at Laboratory of Distributed Systems - UFCG</div></div></div></div>
</div>