incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [DISCUSS]API request throttling
Date Thu, 20 Dec 2012 14:52:35 GMT
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.saxena@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.Mehta@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.Huang@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.Vittal@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" <jlk@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.chen@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
> >>>>
> >


Mime
View raw message