Good point, will add to FS. Thanks -min
On 12/20/12 6:52 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: >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 >> >>>> >> > >
