Sorry, typo, I meant that we will not set limit for root admin. Thanks -min
On 12/20/12 10:12 AM, "Min Chen" <[email protected]> wrote: >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 >>> > > >> >
