Current design is to set API call limit per account, and for root admin we will set such limit. An API to show remaining counts per account sounds good, I can add that into FS.
Thanks -min On 12/20/12 12:48 AM, "Koushik Das" <[email protected]> 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. > >Should the API call limit be specific to roles available - normal user, >domain admin, root admin? > >Thanks, >Koushik > >> -----Original Message----- >> From: Alex Huang [mailto:[email protected]] >> Sent: Thursday, December 20, 2012 12:54 AM >> To: [email protected] >> 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:[email protected]] >> > 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" <[email protected]> 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 <[email protected]> >> > > 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 >> > > >
