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 >>>> >
