<div dir="ltr">Sending out a heads up that the initial spec [0] merged. <div><br></div><div>[0] <a href="https://review.openstack.org/#/c/440815/">https://review.openstack.org/#/c/440815/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
For those that are interested in nested quotas, there is proposal on how to address this forming in openstack-dev (and any comments on the review should be made to <a href="https://review.openstack.org/#/c/363765" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/363765</a>).<br>
<br>
This proposal has the benefits (if I can summarise) that<br>
<br>
- Quota limits will be centrally managed in Keystone so the quota data will be close to the project for creation/deletion/admin.<br>
- The usage data remains within each project avoiding dependencies and risks of usage data getting out of sync.<br>
- With a central store for quotas, there is increased opportunity for consistency. Given the complexity of quotas and nested projects, this would improve operator and end user understanding. The exact model is still for confirmation though.<br>
<br>
We’ll have a forum discussion (<a href="http://forumtopics.openstack.org/cfp/details/9" rel="noreferrer" target="_blank">http://forumtopics.openstack.<wbr>org/cfp/details/9</a>) in Boston too but feel free to give input to <a href="https://review.openstack.org/#/c/363765" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/363765</a> so we can use Boston as the opportunity to agree on the approach and next steps.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 30.03.17, 19:52, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
    The near final draft of the unified limits spec is up now -<br>
    <a href="https://review.openstack.org/#/c/440815/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/440815/</a><br>
<br>
    If you have not yet wandered in, now is the time, we're going to make<br>
    the final go / no go the end of this week.<br>
<br>
        -Sean<br>
<br>
    On 03/17/2017 06:36 AM, Sean Dague wrote:<br>
    > Background:<br>
    ><br>
    > At the Atlanta PTG there was yet another attempt to get hierarchical<br>
    > quotas more generally addressed in OpenStack. A proposal was put forward<br>
    > that considered storing the limit information in Keystone<br>
    > (<a href="https://review.openstack.org/#/c/363765/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/363765/</a>). While there were some<br>
    > concerns on details that emerged out of that spec, the concept of the<br>
    > move to Keystone was actually really well received in that room by a<br>
    > wide range of parties, and it seemed to solve some interesting questions<br>
    > around project hierarchy validation. We were perilously close to having<br>
    > a path forward for a community request that's had a hard time making<br>
    > progress over the last couple of years.<br>
    ><br>
    > Let's keep that flame alive!<br>
    ><br>
    ><br>
    > Here is the proposal for the Unified Limits in Keystone approach -<br>
    > <a href="https://review.openstack.org/#/c/440815/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/440815/</a>. It is intentionally a high<br>
    > level spec that largely lays out where the conceptual levels of control<br>
    > will be. It intentionally does not talk about specific quota models<br>
    > (there is a follow on that is doing some of that, under the assumption<br>
    > that the exact model(s) supported will take a while, and that the<br>
    > keystone interfaces are probably not going to substantially change based<br>
    > on model).<br>
    ><br>
    > We're shooting for a 2 week comment cycle here to then decide if we can<br>
    > merge and move forward during this cycle or not. So please<br>
    > comment/question now (either in the spec or here on the mailing list).<br>
    ><br>
    > It is especially important that we get feedback from teams that have<br>
    > limits implementations internally, as well as any that have started on<br>
    > hierarchical limits/quotas (which I believe Cinder is the only one).<br>
    ><br>
    > Thanks for your time, and look forward to seeing comments on this.<br>
    ><br>
    >   -Sean<br>
    ><br>
<br>
<br>
    --<br>
    Sean Dague<br>
    <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
    ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</div></div></blockquote></div><br></div>