Hi Sowmya,
I have reviewed your test plan, looks good to me. I have uploaded a new
version of spreadsheet with my comments updated there, please click your
test plan to see my comments. FS is also updated to date to reflect plugin
implementation.
Thanks
-min
On 2/5/13 9:48 PM, "Sowmya Krishnan" <sowmya.krish...@citrix.com> wrote:
>I've uploaded an initial draft of the test cases here:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Throttl
>ing+Test+Cases
>
>Please let me know if any comments or if any new cases could be added.
>Some of the verification steps related to the UI cases may be a bit hazy.
>Feel free to comment.
>
>Thanks,
>Sowmya
>
>-----Original Message-----
>From: Min Chen [mailto:min.c...@citrix.com]
>Sent: Friday, February 01, 2013 10:15 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS]API request throttling
>
>If UI is firing queryAsynJobResult on behalf of the user, then it will be
>counted. With recent event framework merge, can UI be notified with job
>status change instead of constantly polling?
>
>-min
>
>Sent from my iPhone
>
>On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan"
><sowmya.krish...@citrix.com> wrote:
>
>> Sorry...I should've been more clear. My question here is, from the UI,
>>when a user fires an async job, do the queryAsyncJobResult APIs also get
>>counted?
>>
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Friday, February 01, 2013 4:44 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS]API request throttling
>>
>> I think she's talking about the CloudStack UI
>>
>> On 1/31/13 2:03 PM, "Min Chen" <min.c...@citrix.com> wrote:
>>
>>> Hi Sowmya,
>>>
>>> I still could not understand your statement below about
>>> queryAsyncJob api. By searching the codebase, I didn't see anywhere
>>> in our code where CS itself triggers this command internally. For
>>> example, in deployVMCmd api, which will create an async job and
>>> return the job id to user, but CS itself internally will not
>>> automatically poll the job result on behalf of the user, so our
>>>current implementation will still count this api as 1.
>>> Did I miss anything here?
>>>
>>> Thanks
>>> -min
>>>
>>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <sowmya.krish...@citrix.com>
>>>wrote:
>>>
>>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>> attacks to CS server, we cannot filter out some APIs in throttling
>>>>>control.
>>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>>> CS server down. Also, I don't understand your comment on
>>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>> is a user API.
>>>>
>>>> You're right queryAsyncJob can be fired independently by user. But I
>>>> was wondering in cases where aysnc jobs are issued by users, it
>>>> results in multiple queryAsyncJob requests fired (not by the user)
>>>> that polls for the job result, and yet, these get counted too
>>>> although it was not directly triggered by the user. I would imagine
>>>> for now, the solution is to have a sufficiently high api limit so
>>>> that a user doesn't encounter the limit too early due to multiple
>>>>aysnc jobs fired in a short duration.
>>>>
>>>> -----Original Message-----
>>>> From: Min Chen [mailto:min.c...@citrix.com]
>>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS]API request throttling
>>>>
>>>> Hi Sowmya,
>>>>
>>>> Thanks for the feedback. See my answers inline.
>>>>
>>>> -min
>>>>
>>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <sowmya.krish...@citrix.com>
>>>>wrote:
>>>>
>>>>> Min, have few questions on this feature while I was coming up with
>>>>> test plan -
>>>>>
>>>>> 1. Do we allow specifying multiple limits based on different
>>>>> intervals
>>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval =
>>>>> 60 sec.
>>>>> Essentially multiple time slices for better granularity and control.
>>>>> If yes, how do I set up this?
>>>> [Min] No, currently we only support specifying one time limit with
>>>> your specified interval through components.xml. For the purpose of
>>>> avoid malicious attacks to CS server, I don't see the point of
>>>> specifying multiple limits for different time slices.
>>>>
>>>>>
>>>>> 2. What is the purpose of resetApiLimitCmd being provided to the
>>>>>User?
>>>>> Can a user not keep invoking this API and reset his counter every
>>>>> time it's exceeding his limit? This should be available only to the
>>>>> admin isn't it?
>>>> [Min] That is the good point, we should only provide reset API to
>>>> admin user. I will fix FS to reflect that.
>>>>
>>>>> 3. Can we have a "negative list" (or a better name) which shouldn't
>>>>> be accounted for throttling? For example, queryAsyncJob could be
>>>>> one candidate since a user cannot really control that.
>>>> [Min] Since the intention of this feature is to avoid malicious
>>>> attacks to CS server, we cannot filter out some APIs in throttling
>>>>control.
>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>> CS server down. Also, I don't understand your comment on
>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>> is a user API.
>>>>
>>>>>
>>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's
>>>>> manual for now, at least for 4.1 release?
>>>>
>>>> [Min] Yes, that is manual for now.
>>>>>
>>>>> Thanks,
>>>>> Sowmya
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pranav Saxena [mailto:pranav.sax...@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>> A proper error code is certainly seems to be the standard . Just
>>>>> for an example , Twitter uses the same for handling their API
>>>>> throttling response errors as well
>>>>>(https://dev.twitter.com/docs/rate-limiting ) .
>>>>> The back-off algorithm discussion I was referring to was for
>>>>> handling automatic triggering of blocked requests but I could not
>>>>> think of a scenario where it might be useful for cloudstack to have
>>>>>such a
>>>>> functionality . Any ideas /suggestions?
>>>>>
>>>>> Regards,
>>>>> Pranav
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>>>
>>>>>> Which brings me to another question: what is the response: is it a
>>>>>> HTTP error code or a normal response that has to be parsed?
>>>>>> The reaction of most users to an error from the cloud is to re-try
>>>>>> -- thereby making the problem worse.
>>>>>>
>>>>>
>>>>> A proper error code is the right way to do it. It only makes the
>>>>> problem worse if it causes the system to behave poorly so we have
>>>>> to design this feature such that processing it doesn't cause
>>>>> considerable performance/scale problem in the system. One
>>>>> possibility is a backoff algorithm (saw some discussion about it
>>>>> but wasn't sure if it was for this), where we hold off the response
>>>>> if it continues to send requests, in effect choking the client.
>>>>>
>>>>> --Alex
>>>>
>>>
>>
