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.b...@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" <s...@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-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