<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Two levels would certainly solve the vast majority of our use cases (i.e. delegation to a VO/Experiment within an envelope). The CERN blog included the expansion to 3 in that there had been some concerns from potential
implementers raised over the algorithms when the nesting went beyond 2. Replacing the per user use case and moving resource ownership to the project would also simplify code in other areas.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Tim<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">John Garbutt <john@johngarbutt.com><br>
<b>Date: </b>Tuesday, 13 March 2018 at 22:08<br>
<b>To: </b>"openstack-sigs@lists.openstack.org" <openstack-sigs@lists.openstack.org><br>
<b>Cc: </b>"user-committee@lists.openstack.org" <user-committee@lists.openstack.org><br>
<b>Subject: </b>Re: [User-committee] [Openstack-sigs] [Scientific] Unified limits and hierarchical project use cases<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><a name="_MailOriginalBody">On Tue, 13 Mar 2018 at 19:36, Tim Bell <</a><a href="mailto:Tim.Bell@cern.ch"><span style="mso-bookmark:_MailOriginalBody">Tim.Bell@cern.ch</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">>
wrote:<o:p></o:p></span></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">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 </span><a href="http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html" target="_blank"><span style="mso-bookmark:_MailOriginalBody">http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">
based on some discussions with Sean where he was looking for more detail.<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">I had forgotton about that blog, thanks for reminding me.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">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:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"></span><a href="https://review.openstack.org/#/c/549766/" target="_blank"><span style="mso-bookmark:_MailOriginalBody">https://review.openstack.org/#/c/549766/</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">I am particularly interested in the use cases that are really blocked with only two levels of hierarchy.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">John<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-bookmark:_MailOriginalBody">-----Original Message-----<br>
From: Lance Bragstad <</span><a href="mailto:lbragstad@gmail.com" target="_blank"><span style="mso-bookmark:_MailOriginalBody">lbragstad@gmail.com</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">><br>
Date: Tuesday, 13 March 2018 at 20:25<br>
To: "</span><a href="mailto:user-committee@lists.openstack.org" target="_blank"><span style="mso-bookmark:_MailOriginalBody">user-committee@lists.openstack.org</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">"
<</span><a href="mailto:user-committee@lists.openstack.org" target="_blank"><span style="mso-bookmark:_MailOriginalBody">user-committee@lists.openstack.org</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">><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>
</span><a href="http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html" target="_blank"><span style="mso-bookmark:_MailOriginalBody">http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><br>
[1] </span><a href="https://review.openstack.org/#/c/549766/" target="_blank"><span style="mso-bookmark:_MailOriginalBody">https://review.openstack.org/#/c/549766/</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><br>
<br>
<br>
<br>
_______________________________________________<br>
openstack-sigs mailing list<br>
</span><a href="mailto:openstack-sigs@lists.openstack.org" target="_blank"><span style="mso-bookmark:_MailOriginalBody">openstack-sigs@lists.openstack.org</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" target="_blank"><span style="mso-bookmark:_MailOriginalBody">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><o:p></o:p></span></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>