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 <[email protected]>: > 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 <[email protected]> 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? > > Inherited 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 created 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 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. > > What remains to implement? > > 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). > > > 2014-03-17 8:04 GMT-03:00 Telles Nobrega <[email protected]>: > >> 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 <[email protected]> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
