Open Stack

Also note that the default rate limiting implementation is in memory.

So if u are running nova in forking 'mode' then each fork will have its own copy of that rate limit information and thus the real rate limit will be (N x rate_limit) with N forks.

At least I believe this is correct. So be careful with that, it would be nice to have a better impl (maybe using turnstile<https://pypi.python.org/pypi/turnstile/>?) as the default someday.

From: Joe Gordon <joe.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>>
Date: Thursday, June 27, 2013 10:59 AM
To: Robert Collins <robertc at robertcollins.net<mailto:robertc at robertcollins.net>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] Nova API rate limiting

Proposed change to nova's default rate limits: https://review.openstack.org/#/c/34774/


On Wed, Jun 26, 2013 at 11:38 PM, Robert Collins <robertc at robertcollins.net<mailto:robertc at robertcollins.net>> wrote:
On 27 June 2013 17:57, Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:
> +1
>
>
>
> What are the limits in the other components ? It would be good to be
> consistent, so we don’t end up with high limits on Nova leading to hitting
> the limits on keystone or glance.

I'm not sure - so far we haven't hit rate limits on other components;
we have hit quota limits in nova and neutron; we have hit bugs due to
other too-low settings or inappropriate default backends (like the
keystone kvs store default, now fixed) : but nothing coupled to the
nova rate limits.

So - I do agree that harmonising things across services is a good
idea, just can't point at any other ones we've had to bump up yet.

-Rob

--
Robert Collins <rbtcollins at hp.com<mailto:rbtcollins at hp.com>>
Distinguished Technologist
HP Cloud Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130628/a53b1505/attachment.html>