<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">+1 </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Would love to see more WGs proposing more use-cases, like this.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">These would be great conversations starters at the summit (forum) as well IMHO.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">/dff</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 28, 2017 at 7:03 AM, Rochelle Grober <span dir="ltr"><<a href="mailto:rochelle.grober@huawei.com" target="_blank">rochelle.grober@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div>this is great, Tom.<br>
<br>
product team should be able to roll this into a support and get to work on Shepard it to the dev team.<br>
<br>
--Rocky<br>
<br>
Sent from HUAWEI AnyOffice<br>
</div>
<div name="x_AnyOffice-Background-Image" style="border-top:1px solid #b5c4df;font-size:14px;line-height:20px;padding:8px">
<div style="word-break:break-all"><b>From:</b>Tom Fifield</div>
<div style="word-break:break-all"><b>To:</b><a href="mailto:user-committee@lists.openstack.org" target="_blank">user-committee@lists.openst<wbr>ack.org</a></div>
<div style="word-break:break-all"><b>Date:</b>2017-01-26 21:01:29</div>
<div style="word-break:break-all"><b>Subject:</b>[User-committee] [Product] Admin-ness+Quota needs write-up</div>
<div><br>
</div>
</div>
</div><div><div class="m_-8004327925814899864h5">
<font size="2"><span style="font-size:10pt">
<div class="m_-8004327925814899864m_7469046986228865931PlainText">Hi Product Team,<br>
<br>
Here's a nice use-case write-up that details a need regarding admin role <br>
scoping in keystone and quotas<br>
<br>
Regards,<br>
<br>
Tom<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: [Openstack-operators] Delegating quota management for all <br>
projects to a user without the admin role?<br>
Date: Thu, 26 Jan 2017 23:36:10 -0000<br>
From: Edmund Rhudy (BLOOMBERG/ 120 PARK) <<a href="mailto:erhudy@bloomberg.net" target="_blank">erhudy@bloomberg.net</a>><br>
Reply-To: Edmund Rhudy <<a href="mailto:erhudy@bloomberg.net" target="_blank">erhudy@bloomberg.net</a>><br>
To: <a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.open<wbr>stack.org</a><br>
<br>
<br>
<br>
I'm looking for a way to allow a user that does not have the admin role <br>
to be able to view and set quota (both Nova/Cinder) for all projects in <br>
an OpenStack cluster. For us, the boundary of a Keystone region is <br>
coterminous with an OpenStack cluster - we don't currently use any sort <br>
of federated Keystone.<br>
<br>
Background: we are involved in a project (not the Keystone variety) for <br>
integrating Bloomberg's internal budget processes closely with <br>
purchasing compute resources. The idea of this system is that you will <br>
purchase some number of standardized compute units and then you can <br>
allocate them to projects in various OpenStack clusters as you wish. In <br>
order to do this, the tool needs to be able to see what Keystone <br>
projects you have access to, see how much quota that project has, and <br>
modify the quota settings for it appropriately.<br>
<br>
For obvious reasons, I'd like to keep the API access for this tool to a <br>
minimum. I know that if all else fails, the goal can be accomplished by <br>
giving it admin access, so I'm keeping that in my back pocket, but I'd <br>
like to exhaust all reasonable options first.<br>
<br>
Allowing the tool to see project memberships and get project information <br>
is easy. The quota part, however, is not. I'm not sure how to accomplish <br>
that delegation, or how to give the tool admin-equivalent access for a <br>
very small subset of the APIs. I'm unfamiliar with Keystone trusts and <br>
am not sure it would be appropriate here anyway, because it would seem <br>
like I'd need to delegate admin control to the role user in order to <br>
allow quota get/set. The only other thing I can think of, and it seems <br>
really off the wall to me, is to:<br>
<br>
* create a local domain in Keystone<br>
* create one user in this local domain per every Keystone project and <br>
add it to that project<br>
* give this user a special role that allows it to set quotas for its project<br>
* set up a massive many-to-one web of trusts where all of these users <br>
are delegated back to the tool's account<br>
<br>
This solution seems very convoluted, and the number of trusts the tool <br>
will need to know about is going to grow linearly with the number of <br>
projects in Keystone.<br>
<br>
The clusters in question are all running Liberty, with Keystone v3 <br>
available. Keystone is in a single-domain configuration, where the <br>
default domain is sourcing users from LDAP and all other information is <br>
stored in SQL.<br>
<br>
Anyone have any thoughts, or am I SOL and just have to give this thing <br>
admin access and make sure the creds stay under lock and key?<br>
</div>
</span></font>
</div></div></div>
<br>______________________________<wbr>_________________<br>
User-committee mailing list<br>
<a href="mailto:User-committee@lists.openstack.org" target="_blank">User-committee@lists.openstack<wbr>.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/user-com<wbr>mittee</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-8004327925814899864gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font size="1"><span style="font-family:tahoma,sans-serif">Flanders | OpenStack Foundation | Community Manager (Cloud Application Communities)<br><a href="http://superuser.openstack.org/articles/meet-openstack-s-community-wrangler-david-flanders" target="_blank">http://superuser.openstack.<wbr>org/articles/meet-openstack-s-<wbr>community-wrangler-david-<wbr>flanders</a></span></font></div></div></div></div>
</div></div>