<div dir="ltr"><br><div class="gmail_extra">On Tue, Jun 28, 2016 at 3:38 AM, Henry Nash <span dir="ltr"><<a href="mailto:henrynash9@mac.com" target="_blank">henrynash9@mac.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Matt,<div><br></div><div>So the keystone changes were intentional. From Mitaka onwards, a domain is represented as a project which is “acting as a domain” (it has an attribute “is_domain” set to true). The situation you describe, where what were top level projects now have the project acting as the default domain as their parent, is what I would expect to happen after the update.</div><div><br></div><div>During Mitaka development, we  worked with the cinder folks - who were to re-designing their quota code anyway - and this was modified to take account of the project structure. I’m not sure if the quota semantics you see are what was intended (I’ll let the cinder team comment). Code can, if desired, distinguish the case of top projects that are at the top level, vs projects somewhere way down the hierarchy, by looking at the parent and seeing if it is a project acting as a domain.</div></div></blockquote><div><br></div><div>Just to add to Henry's answer, checking if the parent is a project acting as a domain is just matter of comparing the parent_id with the domain_id, if they are equal, it means the parent is a project acting as a domain. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Henry</div><div>keystone core<br><div><blockquote type="cite"><div><div class="h5"><div>On 27 Jun 2016, at 17:13, Matt Fischer <<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">We upgraded our dev environment last week to Keystone stable/mitaka. Since then we're unable to show or set quotas on projects of which the admin is not a member. Looking at the cinder code, it seems that cinder is pulling a project list and attempting to determine a hierarchy.  On Liberty Keystone, projects seem to lack parents:<div><br></div><div><Project description=Admin Tenant, domain_id=default, enabled=True, id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': u'<a href="https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'" target="_blank">https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'</a>}, name=admin, parent_id=None, subtree=None></div><div><br></div><div>In Mitaka, it seems that projects are children of the default domain:</div><div><br></div><div><Project description=Admin Tenant, domain_id=default, enabled=True, id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': u'<a href="http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'" target="_blank">http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'</a>}, name=admin, parent_id=default, subtree=None><br><div><br></div><div>In Liberty since all projects were parentless, the authorize_* code blocks were skipped since both conditionals were false:</div><div><br></div><div><a href="https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191" target="_blank">https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191</a><br></div><div><br></div><div>But now in Mitaka, the code is run, and it fails out since the projects are "brothers", both with the parent of the default domain, but not hierarchically related.</div><div><br></div><div>Previously it was a useful ability for us to be able to (as admins) set and view  quotas for cinder projects. Now we need to scope into the user's project to even be able to view their quotas, much less change them. This seems broken, but I'm not sure where the issue is or why the keystone behavior changed. Is this the expected behavior?</div><div><br></div></div></div></div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div><br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_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>
</div></div>