[openstack-dev] Hierarchicical Multitenancy Discussion

Raildo Mascena raildom at gmail.com
Fri May 9 13:39:44 UTC 2014


Hello Vish,

The implementation was done that way because it would facilitating
compatibility of hierarchical projects with Keystone, for example to get a
token, I would have to change the whole implementation to get the inherited
roles, or for example to list roles, among other features,  for this POC
this was a quick and simple, but i believe that we can discuss the best
solution.


2014-05-06 20:08 GMT-03:00 Vishvananda Ishaya <vishvananda at gmail.com>:

> 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
>
>
>
> _______________________________________________
> 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/20140509/a067a20a/attachment.html>


More information about the OpenStack-dev mailing list