Open Stack

On Tue, Mar 14, 2017 at 10:36 AM, Lance Bragstad <lbragstad at 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 <rodrigodsousa at 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 <adriant at 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-request at 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-request at 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-request at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170314/c58b62f3/attachment.html>