[Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC
lbragstad at gmail.com
Mon Apr 10 20:27:59 UTC 2017
Sending out a heads up that the initial spec  merged.
On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell <Tim.Bell at cern.ch> wrote:
> 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 https://review.openstack.org/#/c/363765).
> This proposal has the benefits (if I can summarise) that
> - Quota limits will be centrally managed in Keystone so the quota data
> will be close to the project for creation/deletion/admin.
> - The usage data remains within each project avoiding dependencies and
> risks of usage data getting out of sync.
> - 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.
> We’ll have a forum discussion (http://forumtopics.openstack.
> org/cfp/details/9) in Boston too but feel free to give input to
> https://review.openstack.org/#/c/363765 so we can use Boston as the
> opportunity to agree on the approach and next steps.
> On 30.03.17, 19:52, "Sean Dague" <sean at dague.net> wrote:
> The near final draft of the unified limits spec is up now -
> If you have not yet wandered in, now is the time, we're going to make
> the final go / no go the end of this week.
> On 03/17/2017 06:36 AM, Sean Dague wrote:
> > Background:
> > At the Atlanta PTG there was yet another attempt to get hierarchical
> > quotas more generally addressed in OpenStack. A proposal was put
> > that considered storing the limit information in Keystone
> > (https://review.openstack.org/#/c/363765/). While there were some
> > concerns on details that emerged out of that spec, the concept of the
> > move to Keystone was actually really well received in that room by a
> > wide range of parties, and it seemed to solve some interesting
> > around project hierarchy validation. We were perilously close to
> > a path forward for a community request that's had a hard time making
> > progress over the last couple of years.
> > Let's keep that flame alive!
> > Here is the proposal for the Unified Limits in Keystone approach -
> > https://review.openstack.org/#/c/440815/. It is intentionally a high
> > level spec that largely lays out where the conceptual levels of
> > will be. It intentionally does not talk about specific quota models
> > (there is a follow on that is doing some of that, under the
> > that the exact model(s) supported will take a while, and that the
> > keystone interfaces are probably not going to substantially change
> > on model).
> > We're shooting for a 2 week comment cycle here to then decide if we
> > merge and move forward during this cycle or not. So please
> > comment/question now (either in the spec or here on the mailing
> > It is especially important that we get feedback from teams that have
> > limits implementations internally, as well as any that have started
> > hierarchical limits/quotas (which I believe Cinder is the only one).
> > Thanks for your time, and look forward to seeing comments on this.
> > -Sean
> Sean Dague
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators