<div dir="ltr">Rodrigo,<div><br></div><div>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.</div><div><br></div><div><br></div><div>[0] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte <span dir="ltr"><<a href="mailto:rodrigodsousa@gmail.com" target="_blank">rodrigodsousa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Adrian,<div><div><br class="m_6100159448827737811m_8919781800749074352gmail-Apple-interchange-newline">In project hierarchies, it is not that simple to have a "tree admin". Imagine you have something like the following:</div><div><br></div><div>A -> B -> C</div><div><br></div><div>You are an admin of project C and want to create a project called "secret_D" under C:</div><div><br></div><div>A -> B -> C -> secret_D</div><div><br></div><div>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.</div></div><div><br></div><div>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 :)</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 12:24 AM, Adrian Turjak <span dir="ltr"><<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Keystone Devs,<br>
<br>
I've been playing with subtrees in Keystone for the last while, and one<br>
thing that hit me recently is that as admin, I still can't actually do<br>
subtree_as_list unless I have a role in all projects in the subtree.<br>
This is kind of silly.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I can understand why this limitation was implemented, but it's also a<br>
frustrating constraint because as an admin, I have the power to add<br>
myself to all these projects anyway, why then can't I just list them?</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Right now if I want to get a list of all the subtree projects I need to<br>
do subtree_as_ids, then list ALL projects, and then go through that list<br>
grabbing out only the projects I want. This is a pointless set of<br>
actions, and having to get the full project list when I just need a<br>
small subset is really wasteful.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Beyond the admin case, people may in fact want certain roles to be able<br>
to see the full subtree regardless of access. In fact I have a role<br>
'project_admin' which allows you to edit your own roles within the scope<br>
of your project, including set those roles to inherit down, and create<br>
subprojects. If you have the project_admin role, it would make sense to<br>
see the full subtree regardless of your actually having access to each<br>
element in the subtree or not.<br>
<br>
Looking at the code in Keystone, I'm not entirely sure there is a good<br>
way to set role based policy for this given how it was setup. Another<br>
option might be to introduce a filter which allows listing of<br>
subprojects. Project list is already an admin/cloud_admin only command<br>
so there is no need to limit it, and the filter could be as simple as<br>
'subtree=<project_id>' and would make getting subtrees as admin, or a<br>
given admin-like role, actually doable without the pain of roles everywhere.<br>
<br>
The HMT stuff in Keystone is very interesting, and potentially very<br>
useful, but it also feels like so many of the features are a little<br>
half-baked. :(<br>
<br>
Anyone with some insight into this and is there any interest in making<br>
subtree listing more flexible/useful?<br>
<br>
Cheers,<br>
Adrian Turjak<br>
<br>
<br>
Further reading:<br>
<a href="https://github.com/openstack/keystone-specs/blob/master/specs/keystone/kilo/project-hierarchy-retrieval.rst" rel="noreferrer" target="_blank">https://github.com/openstack/k<wbr>eystone-specs/blob/master/spec<wbr>s/keystone/kilo/project-hierar<wbr>chy-retrieval.rst</a><br>
<a href="https://bugs.launchpad.net/keystone/+bug/1434916" rel="noreferrer" target="_blank">https://bugs.launchpad.net/key<wbr>stone/+bug/1434916</a><br>
<a href="https://review.openstack.org/#/c/167231" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/167231</a><br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_6100159448827737811m_8919781800749074352gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#666666">Rodrigo Duarte Sousa<br></font></div><div><font color="#666666">Senior Quality Engineer @ Red Hat<br></font></div><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">MSc</span><span style="color:rgb(102,102,102)"></span><span style="color:rgb(102,102,102)"> in Computer Science</span><br><font color="#3333ff"><a href="http://rodrigods.com" target="_blank">http://<font color="#3333ff">rodrigods.com</font></a></font></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>