On Tue, Mar 14, 2017 at 10:36 AM, Lance Bragstad <lbrags...@gmail.com> wrote:
> Rodrigo, > > Isn't what you just described the reseller use case [0]? Was that work > ever fully finished? I thought I remember having discussions in Tokyo about > it. > You are right, one of the goals of reseller is to have an even stronger separation in the hierarchy by having subdomains, but this is not implemented yet. However, I was referring only to the project hierarchy and having or not inherited role assignments to grant access to the subtree. > > > [0] http://specs.openstack.org/openstack/keystone-specs/ > specs/keystone/mitaka/reseller.html > > On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte <rodrigodso...@gmail.com> > wrote: > >> Hi Adrian, >> >> In project hierarchies, it is not that simple to have a "tree admin". >> Imagine you have something like the following: >> >> A -> B -> C >> >> You are an admin of project C and want to create a project called >> "secret_D" under C: >> >> A -> B -> C -> secret_D >> >> This is an example of a hierarchy where the admin of project A is not >> supposed to "see" the whole tree. Of course we could implement this in a >> different way, like using a flag "secret" in project "secret_D", but the >> implementation we chose was the one that made more sense for the way role >> assignments are organized. For example, we can assign to project A admin an >> inherited role assignment, which will give access to the whole subtree and >> make it impossible to create a "secret_D" project like we defined above - >> it is basically a choice between the possibility to have "hidden" projects >> or not in the subtree. >> >> However, we can always improve! Please submit a spec where we will be >> able to discuss in further detail the options we have to improve the >> current UX of the HMT feature :) >> >> On Tue, Mar 14, 2017 at 12:24 AM, Adrian Turjak <adri...@catalyst.net.nz> >> wrote: >> >>> Hello Keystone Devs, >>> >>> I've been playing with subtrees in Keystone for the last while, and one >>> thing that hit me recently is that as admin, I still can't actually do >>> subtree_as_list unless I have a role in all projects in the subtree. >>> This is kind of silly. >> >> >>> I can understand why this limitation was implemented, but it's also a >>> frustrating constraint because as an admin, I have the power to add >>> myself to all these projects anyway, why then can't I just list them? >> >> >>> Right now if I want to get a list of all the subtree projects I need to >>> do subtree_as_ids, then list ALL projects, and then go through that list >>> grabbing out only the projects I want. This is a pointless set of >>> actions, and having to get the full project list when I just need a >>> small subset is really wasteful. >> >> >>> Beyond the admin case, people may in fact want certain roles to be able >>> to see the full subtree regardless of access. In fact I have a role >>> 'project_admin' which allows you to edit your own roles within the scope >>> of your project, including set those roles to inherit down, and create >>> subprojects. If you have the project_admin role, it would make sense to >>> see the full subtree regardless of your actually having access to each >>> element in the subtree or not. >>> >>> Looking at the code in Keystone, I'm not entirely sure there is a good >>> way to set role based policy for this given how it was setup. Another >>> option might be to introduce a filter which allows listing of >>> subprojects. Project list is already an admin/cloud_admin only command >>> so there is no need to limit it, and the filter could be as simple as >>> 'subtree=<project_id>' and would make getting subtrees as admin, or a >>> given admin-like role, actually doable without the pain of roles >>> everywhere. >>> >>> The HMT stuff in Keystone is very interesting, and potentially very >>> useful, but it also feels like so many of the features are a little >>> half-baked. :( >>> >>> Anyone with some insight into this and is there any interest in making >>> subtree listing more flexible/useful? >>> >>> Cheers, >>> Adrian Turjak >>> >>> >>> Further reading: >>> https://github.com/openstack/keystone-specs/blob/master/spec >>> s/keystone/kilo/project-hierarchy-retrieval.rst >>> https://bugs.launchpad.net/keystone/+bug/1434916 >>> https://review.openstack.org/#/c/167231 >>> >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Rodrigo Duarte Sousa >> Senior Quality Engineer @ Red Hat >> MSc in Computer Science >> http://rodrigods.com >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Rodrigo Duarte Sousa Senior Quality Engineer @ Red Hat MSc in Computer Science http://rodrigods.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
