Open Stack

Sending out a heads up that the initial spec [0] merged.

[0] https://review.openstack.org/#/c/440815/

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.
>
> 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
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170410/1da73065/attachment.html>