[openstack-dev] [Keystone] [Glance] Centralizing Quotas and New Quotas in Glance

Dolph Mathews dolph.mathews at gmail.com
Tue Apr 30 17:31:14 UTC 2013


On Tue, Apr 30, 2013 at 10:35 AM, Mark Washenberger <
mark.washenberger at markwash.net> wrote:

> Hi all,
>
> During the summit there was some discussion about centralizing quotas to
> ease administration and support domain-level quotas that would span
> endpoints (i.e. you might have a Nova instance limit of 10 that is met when
> you have 2 instances in Region East and 8 instances in Region West.)
>
> As a brief summary, this was my estimate of the reception of the various
> levels of centralization that were discussed:
>
> 1) Central administration of quota limits - very high level of support
> 2) Central storage of quota limits - high level of support, some notable
> dissent
> 3) Central tracking of quota usage - no consensus
>
4) Central enforcement of quota limits - virtually no support, consensus
> against this approach
>

I understood the opposition to 4 to apply to 3 as well (someone correct me
if I'm wrong).


>
> As we are looking at adding quotas to Glance during Havana, I have a few
> questions about this effort.
>
> - Who is planning work on centralized quotas during Havana and when/where
> are any discussions about this work happening? Are there any series targets
> yet?
>

I haven't heard any discussion regarding quotas since the summit, but the
quota storage work is being tracked here:

  https://blueprints.launchpad.net/keystone/+spec/store-quota-data


>
> - If central storage of quota limits is to be adopted, do we plan for
> quotas to lose some of their consistency? To explain, right now, quotas are
> fairly consistent--if my limit is 10 instances, its very difficult for me
> to end up with 11 instances, even if my limit just recently changed. But if
> limits are stored elsewhere, there may be an accepted propagation delay
> that would make it possible to unintentionally violate my quota.
>
> - If losses to the consistency of quotas are not acceptable, what are the
> performance implications of Nova having to call out to another service to
> determine a quota limit prior to completing a server create request? (This
> part sounds scary to me!)
>
>
> Thanks for your help!
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/6972cc96/attachment.html>


More information about the OpenStack-dev mailing list