[Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC

Tim Bell Tim.Bell at cern.ch
Thu Mar 30 18:44:46 UTC 2017


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.

Tim

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 -
    https://review.openstack.org/#/c/440815/
    
    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.
    
    	-Sean
    
    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 forward
    > 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 questions
    > around project hierarchy validation. We were perilously close to having
    > 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 control
    > will be. It intentionally does not talk about specific quota models
    > (there is a follow on that is doing some of that, under the assumption
    > that the exact model(s) supported will take a while, and that the
    > keystone interfaces are probably not going to substantially change based
    > on model).
    > 
    > We're shooting for a 2 week comment cycle here to then decide if we can
    > merge and move forward during this cycle or not. So please
    > comment/question now (either in the spec or here on the mailing list).
    > 
    > It is especially important that we get feedback from teams that have
    > limits implementations internally, as well as any that have started on
    > 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
    http://dague.net
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    



More information about the OpenStack-operators mailing list