Open Stack

While I think there is probably some value in rate limiting API calls, I
think your "user wants to launch x000 instances" is extremely limited.
There's maybe 1 or 2 (or 0) operators that have that amount of spare
capacity just sitting around that they can allow a user to have a quota of
2000 instances without doing an infrastructure build-out.

The real value in rate limiting, as long as it can be done without limiting
performance, is in handling users who are DoSing the APIs, intentionally or
not.

On Thu, Sep 10, 2015 at 2:38 AM, Jean-Daniel Bonnetot <
jean-daniel.bonnetot at ovh.net> wrote:

> The use case is a crossing of two
> 1. As user, I want to use X,000 instances, in order to accept the load
> increment during my activity (long period). So the boot rate for instances
> is low.
> 2. As operator, I need to be able to set high quota (thousands of
> instances to cover the first use case) AND prevent users to start too many
> of instances at a time. In other word, force my client to use a boot rate
> « low ».
> --
> Jean-Daniel
> @pilgrimstack
>
>
>
>
> Le 9 sept. 2015 à 18:36, David Medberry <openstack at medberry.net> a écrit :
>
> Your users should also have reasonable quotas set. If they can boot
> thousands of instances, you may have a quota issue to address. (No problem
> with the blueprint or need to set an overall limit though--just that you
> should be able to address this without waiting for that to land.)
>
> On Mon, Sep 7, 2015 at 8:48 AM, Jean-Daniel Bonnetot <
> jean-daniel.bonnetot at ovh.net> wrote:
>
>> Hi,
>>
>> I try to limit the max instances a user can create per minute.
>>
>> With rate limit, we can limit the number of call/min on POST */servers
>> for example.
>> But the user can still use the max_count paramteter in his API call to
>> boot dozen of thousand of instances and make the scheduler crazy.
>>
>> I’m pretty sure that there is a possiblity to limit the max_count and so
>> define a max instances/min.
>> Do you know something to do it?
>>
>> --
>> Jean-Daniel
>> @pilgrimstack
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
>
> _______________________________________________
> 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/20150910/de89f077/attachment.html>