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 <mailto: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 > <mailto:OpenStack-operators@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > <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
