incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: [DISCUSS]API request throttling
Date Thu, 20 Dec 2012 18:11:05 GMT
Good point, will add to FS.

Thanks
-min

On 12/20/12 6:52 AM, "Alex Huang" <Alex.Huang@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.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