Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140414/3ffe743b/attachment.html>