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 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" 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-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
