<div dir="ltr">Hey Lance,<div><br></div><div>Thanks for putting this on our radar. Personally I need to read Tim's blog and understand a bit more about what this is exactly. I do remember a thread last year that got a lot of responses of which hierarchical quotas[0]</div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-operators/2017-January/012436.html">http://lists.openstack.org/pipermail/openstack-operators/2017-January/012436.html</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 13, 2018 at 4:07 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class="">On Tue, 13 Mar 2018 at 19:36, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>> wrote:<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lance,<br>
<br>
Thanks for reaching out. BTW, we're not set on how hierarchical quotas should work but we were trying to write down a possible scenario. There was also quite a lot of interest from other labs so I'm adding the Scientific SIG to the thread.<br>
<br>
We also expanded a little on the approach in <a href="http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html" rel="noreferrer" target="_blank">http://openstack-in-<wbr>production.blogspot.fr/2017/<wbr>07/nested-quota-models.html</a> based on some discussions with Sean where he was looking for more detail.<br>
</blockquote><div dir="auto"><br></div></span><div dir="auto">I had forgotton about that blog, thanks for reminding me.</div><div dir="auto"><br></div><div dir="auto">My current proposal is really going for something as simple as possible that unblocks a bunch of use cases in a way that we can discover what might need building next:</div><div dir="auto"><a href="https://review.openstack.org/#/c/549766/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/549766/</a><br></div><div dir="auto"><br></div><div dir="auto">It limits the hierarchy to two levels for coding (and operational) simplicity. I was thinking of the community / virtual organisation model (VOMS/EGI AAI), where the community gets an amount of quota. That community is then allowed one level of sub projects that can also use some resources from the pool of quota given to the whole community. Given you must count how many resources are owned by all projects in the tree, there is a strong argument towards keeping the tree as small as possible.</div><div dir="auto"><br></div><div dir="auto">I am particularly interested in the use cases that are really blocked with only two levels of hierarchy.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">John</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">-----Original Message-----<br>
From: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>><br>
Date: Tuesday, 13 March 2018 at 20:25<br>
To: "<a href="mailto:user-committee@lists.openstack.org" target="_blank">user-committee@lists.<wbr>openstack.org</a>" <<a href="mailto:user-committee@lists.openstack.org" target="_blank">user-committee@lists.<wbr>openstack.org</a>><br>
Subject: [User-committee] Unified limits and hierarchical project use cases<br>
<br>
Hey all,<br>
<br>
Unified limits and hierarchical quotas was a big topic during the Rocky<br>
PTG. With the ground work laid in Queens, most of the discussions for<br>
Rocky focused on different enforcement models.<br>
<br>
For those who haven't been keeping up with the unified limits<br>
discussions, an enforcement model is an opinionated way of how a quota,<br>
or limit, should behave with respect to other parent, sibling, or child<br>
projects. It's possible to think of multiple ways in which enforcement<br>
can be done, and it's not that there is one right way and the rest are<br>
wrong, just a difference in how quotas might need to behave for<br>
different deployments.<br>
<br>
During the discussions at the PTG, everyone in the room agreed that we<br>
don't really understand how people are using hierarchical projects. This<br>
makes it tough to design a quota or limit enforcement model without<br>
understanding how people expect it to work. Tim Bell has taken some time<br>
to write down how he expects a quota system to work for CERN's use case<br>
[0], which we'll be working into a specification for an enforcement<br>
model [1].<br>
<br>
We'd like to see if the User Committee can help us collect more<br>
information from users and operators about how they expect enforcement<br>
to be done. Do your deployments use hierarchical projects? How do you<br>
manage quota today? Do you have expectations about how quotas and limits<br>
work across related projects (e.g. setting quota on a parent project<br>
affects the children in X ways)?<br>
<br>
Depending on responses, it'd be nice to aggregate the results, kind of<br>
like what Tim provided, so that we can write a specification for them.<br>
<br>
Is there a way we can leverage the UC to collect this information?<br>
<br>
Thanks,<br>
<br>
Lance<br>
<br>
[0]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>February/111999.html</a><br>
[1] <a href="https://review.openstack.org/#/c/549766/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/549766/</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br></div></div>
openstack-sigs mailing list<br>
<a href="mailto:openstack-sigs@lists.openstack.org" target="_blank">openstack-sigs@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-sigs</a><br>
</blockquote></div></div>
<br>______________________________<wbr>_________________<br>
User-committee mailing list<br>
<a href="mailto:User-committee@lists.openstack.org">User-committee@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/user-<wbr>committee</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr">Kind regards,<br><br>Melvin Hillsman</div><div dir="ltr"><a href="mailto:mrhillsman@gmail.com" style="color:rgb(17,85,204)" target="_blank">mrhillsman@gmail.com</a><br>mobile: (832) 264-2646<br></div></div></div></div></div></div></div></div></div>
</div>