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.bonne...@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 <openst...@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.bonne...@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@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 > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
