<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span style="font-size:12.8000001907349px">Hi,</span><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">While developing Nested Quota Driver for Cinder, when performing show/update/delete following restrictions apply :-</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">1. show : Only user who is admin or admin in parent or admin in root project should be able to perform show/view the quota of the leaf projects.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">2. update : Only user admin in parent or admin in root project should be able to perform update.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">3. delete : Only user admin in parent or admin in root project should be able to perform delete.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">In order to get the parent information or child list in nested hierarchy calls need to be made to keystone. So as part of these changes do we want to introduce 2 new roles in cinder one for project_admin and one for root_admin so that the token can be scoped at project/root level and only the permissible operation at the respective levels as described above can be allowed.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">For example  :-</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">A</div><div style="font-size:12.8000001907349px"> |</div><div style="font-size:12.8000001907349px">B</div><div style="font-size:12.8000001907349px"> |</div><div style="font-size:12.8000001907349px">C</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">cinder quota-update C (should only be permissible from B or A)</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">This can achieved either by :-</div><div style="font-size:12.8000001907349px">1. Introducing project_admin or cloud_admin rule in policy.json and later populate the [1] with respective target[2][3]. Minises code changes and gives the freedom to operators to modify policy.json and tune changes accordingly.</div><div style="font-size:12.8000001907349px">2. Not introduce these 2 roles in policy.json by just make code changes and additional logic in code to handle this but using this option we can go to at max 1 level of heirarchy as in-order to fetch more parent we will need to make a keystone call.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Need opinion on which option can be helpful in longterm.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">-Vilobh</div><div style="font-size:12.8000001907349px">[1] <a href="https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L33" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L33</a></div><div style="font-size:12.8000001907349px">[2] <a href="https://github.com/openstack/cinder/blob/master/cinder/api/extensions.py#L379" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/api/extensions.py#L379</a></div><div style="font-size:12.8000001907349px">[3] <a href="https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L109" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L109</a></div></div></div></div>