There also should be api to reset the count just in case we got it completely wrong.
--Alex > -----Original Message----- > From: Pranav Saxena [mailto:pranav.sax...@citrix.com] > Sent: Thursday, December 20, 2012 2:21 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [DISCUSS]API request throttling > > +1 to what Nitin says . Global limits and flexibility to admin is something > which > is highly desirable . > > It really gets interesting when you consider that you could further make > decisions based on parameters, such as a specific user and the application > function when you consider throttling issues. > > Also are we planning to build the code in such a way that when we take into > consideration the "throttling time " , do we have some kind off a back-off > algorithm to trigger the request again automatically ( may be in some > scenarios , not sure though ) , when we're being throttled (like come back > after a "restore rate" period, specific to the type of API request one is > making ) or the user has to make the request again manually every time > once he is throttled. This might sound vague but I am just curious to know if > such a scenario can exist or not . > > Regards, > Pranav > > > -----Original Message----- > From: Nitin Mehta [mailto:nitin.me...@citrix.com] > Sent: Thursday, December 20, 2012 3:04 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS]API request throttling > > > > On 20-Dec-2012, at 2:18 PM, Koushik Das wrote: > > > +1 to the idea. > > > > Should there be some API to show how many API calls are remaining for a > particular user for the given interval? And should this call get counted as > well? > Currently in UI if you are using wizard to deploy a VM multiple API calls are > made but may not be obvious to the user. If there is a limit then the number > of exact API calls for each top level operation should be clearly > communicated to end user. > > > > Good point. Currently UI uses list API, queryAsyncJob api's to fetch the > progress of async jobs and calls them every so often. > > > Should the API call limit be specific to roles available - normal user, > > domain > admin, root admin? > > I believe besides having global limits, root admin should have the > flexibility of > changing this just like we have it for other account limits like VMs, > snapshots, > templates he can create etc. Admin would definitely want that flexibility. > > > > > > Thanks, > > Koushik > > > >> -----Original Message----- > >> From: Alex Huang [mailto:alex.hu...@citrix.com] > >> Sent: Thursday, December 20, 2012 12:54 AM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: RE: [DISCUSS]API request throttling > >> > >> The important part is the count is separated from other tables, which > >> the spec specifies. Then if we find problems we can. > >> > >> --Alex > >> > >>> -----Original Message----- > >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > >>> Sent: Wednesday, December 19, 2012 11:18 AM > >>> To: CloudStack DeveloperList > >>> Subject: Re: [DISCUSS]API request throttling > >>> > >>> I think the purpose of the DB is to support a clustered setup, > >>> otherwise an in-memory counter would suffice. > >>> John's concern on DB performance is pertinent. > >>> I have had good success with MySQL's "UPDATE table SET > >>> counter=counter+1" > >>> to increment counts, but that is specific to MySQL. > >>> Note that the FK is really not necessary -- you could ensure it is > >>> deleted with a background task. > >>> > >>> This opensource project [1] prefers to use a Redis store to track > >>> the counters to enable distributed counting, but I wonder if MySQL's > >>> in-memory table would also work (there's a lot of limitations on the > >>> in-memory store though). > >>> OTOH, a nosql store like Redis might find applications elsewhere. > >>> > >>> [1]https://github.com/klmitch/turnstile#readme > >>> > >>> > >>> On 12/19/12 11:01 AM, "John Kinsella" <j...@stratosec.co> wrote: > >>> > >>>> Looks good - you got the one thing I would have thought of, to be > >>>> able to throttle per account. > >>>> > >>>> I'd suspect that tracking db counts in the db itself could cause a > >>>> DOS, unless the inserts are buffered? > >>>> > >>>> Also, how will the tracking work in clustered manager setups? > >>>> > >>>> I don't know what this "campo" release is which the wiki page speaks of. > >>>> :) > >>>> > >>>> On Dec 19, 2012, at 10:49 AM, Min Chen <min.c...@citrix.com> > >>>> wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> Currently, the legitimate users of CloudStack can occasionally > >>>>> hammer the server with heavy API requests that cause undesirable > >>>>> results, like killing the server, performance issues for other > >>>>> CloudStack users. Also, it may become a mechanism for certain > >>>>> malicious users to do malicious attacks to CloudStack service to > >>>>> cause cloud outage. To prevent certain things happen, we would > >>>>> like to introduce API request throttling feature to limit number > >>>>> of APIs that can be placed by each account within certain time > >>>>> duration and will block API requests if the account is over the > >>>>> limit so that he/she have to retry later. The detailed FS can be > >>>>> found at > >>> > >>>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+ > >>> Thrott > >>>>> ling. > >>>>> > >>>>> Please let me know any comments and suggestions. > >>>>> > >>>>> Thanks > >>>>> -min > >>>> > >>>> Stratosec - Secure Infrastructure as a Service > >>>> o: 415.315.9385 > >>>> @johnlkinsella > >>>> > >
