As these API are fired from UI. Ignore this statement.. this is invalid. "Well, What if backend only likes to have 200 and instead keeps getting 429 till limit is over."
Thanks, .. Parth -----Original Message----- From: Parth Jagirdar [mailto:parth.jagir...@citrix.com] Sent: Thursday, March 07, 2013 4:37 PM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS} API Throttling minimum number of calls per unit of time Well, What if backend only likes to have 200 and instead keeps getting 429 till limit is over. What I meant is, Assume you reached 15 API limit just before you clicked "View IP Addresses" under Network tab. Now when you click that it fired listZones which returned 429 limit reached. Now if you have a loop in place which attempts a retry till you don't get right response(Right response is 200) then we are in trouble. We will raise an error for each listZones that failed and we will now keep on firing listZones till we get a proper response. Only conditions that breaks it is when API limit remaining time reaches 0ms because that's when 200 OK is possible. Hope this helps. Thanks, .. Parth -----Original Message----- From: Min Chen [mailto:min.c...@citrix.com] Sent: Thursday, March 07, 2013 4:28 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS} API Throttling minimum number of calls per unit of time Hi Parth, I don't understand the issue here. After you reach the maximum number of APIs you set, for every API issued after that point and before interval window expires, backend will have to throw user an error, what is the issue here? Thanks -min On 3/7/13 3:41 PM, "Parth Jagirdar" <parth.jagir...@citrix.com> wrote: >Refer to > >CLOUDSTACK-1586 > >I think minimum number to throttle and "API Throttled : ERROR" which >has >1:1 ratio, also needs to be addressed somehow. > >Thanks, >.. Parth > >Thanks, >.. Parth > > >-----Original Message----- >From: Min Chen [mailto:min.c...@citrix.com] >Sent: Tuesday, March 05, 2013 9:54 AM >To: cloudstack-dev@incubator.apache.org >Subject: Re: [DISCUSS} API Throttling minimum number of calls per unit >of time > >This issue has been fixed in both 4.1 and master. A new global setting >"api.throttling.enabled" is introduced. >By default, it is set to false, so no API throttling is enabled. To >enable it, just change the setting to true, and restart MS. FS is also >updated with this information. > >Thanks >-min > >On 3/1/13 6:06 PM, "Min Chen" <min.c...@citrix.com> wrote: > >>Thanks Alex for clarification. I will provide an extra global setting >>to allow user to easily enable/disable this instead of going through >>componentContext.xml. Parth already filed a bug to track this: >>https://issues.apache.org/jira/browse/CLOUDSTACK-1484 >> >>-min >> >>On 3/1/13 5:56 PM, "Alex Huang" <alex.hu...@citrix.com> wrote: >> >>>This is something that everyone writing plugins should think about. >>> >>>A component being enabled does not automatically mean that >>>functionality being enabled. Here, API Throttling component is >>>enabled/disabled through componentcontext.xml but the behavior of >>>whether it should automatically default to setting a limit on api >>>calls is a property of the api throttling component and should not >>>depend on api throttling component being enabled/disabled to set that >>>limit. >>> >>>It's a tricky problem to see because the distinction seems to be so >>>small. You have to look at it from the perspective of the people who >>>touches cloudstack's code. >>> >>>One type of people is the distributor of CloudStack code. He comes >>>in and says I understand CloudStack and I pick the best components to >>>deploy it with. For example, they may choose to put in a different >>>api throttling component to package. He's the person who changes >>>componentContext.xml. >>> >>>Another type of people is the deployer of CloudStack code, usually a >>>system admin. He takes the package from distributor and says I read >>>the documentation and I understand how to use your cloudstack as a >>>package. >>>He's the person who configures CloudStack through configuration >>>variables. >>> >>>Sometimes, these two people are the same person but when we write >>>code we have to think of them as separate people. Therefore, api >>>throttling component should default to not limiting api calls should >>>not rely on the api throttling component being disabled in >>>componentscontext.xml to achieve that functionality. That's >>>functionality that belongs to api throttling after it is enabled. >>> >>>Just think of the case of the deployer upgrading. The distributor >>>decided they want to add this functionality to the release but why >>>should the deployer know that he should disable api throttling in >>>componentscontext.xml? >>> >>>--Alex >>> >>> >>> >>>> -----Original Message----- >>>> From: Min Chen [mailto:min.c...@citrix.com] >>>> Sent: Friday, March 1, 2013 4:39 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: [DISCUSS} API Throttling minimum number of calls per >>>>unit of time >>>> >>>> Currently for 4.1 api throttling is enabled by default since we >>>>include that pluggable service in ComponentContext.xml. Parth, >>>>please file a defect for that, I will fix it. >>>> >>>> Thanks >>>> -min >>>> >>>> On 3/1/13 4:36 PM, "Parth Jagirdar" <parth.jagir...@citrix.com> wrote: >>>> >>>> >That sounds right.. >>>> > >>>> >If you enable throttling then .. you are assumed to know what it >>>>does. >>>> >If you enable throttling then .. you should decide values based on >>>>your >>>> >environment. >>>> > >>>> >Thanks, >>>> >.. Parth >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: David Nalley [mailto:da...@gnsa.us] >>>> >Sent: Friday, March 01, 2013 2:58 PM >>>> >To: cloudstack-dev@incubator.apache.org >>>> >Subject: Re: [DISCUSS} API Throttling minimum number of calls per >>>> >unit of time >>>> > >>>> >On Fri, Mar 1, 2013 at 5:34 PM, Parth Jagirdar >>>> ><parth.jagir...@citrix.com> wrote: >>>> >> All, >>>> >> >>>> >> API throttling number can be set to anything at this point. >>>> >> >>>> >> Suggestions here is to have this number set to a value that is >>>> >>"greater than" number of API that can be fired by any potential >>>>action on >>>> UI. >>>> >> >>>> >> Minimum API for throttling that can be set < Number of API's >>>> >>Any action can fire in unit time. >>>> >> (unit time is 1 second) >>>> >> >>>> >> >>>> >> That said say action X fires 10 API in 2 seconds than having 10 >>>> >>as min number is safe. Or even 8 if we have decent idea of >>>> >>intervals they get fired at.. >>>> >> But for action Y that fires 20 in 2 seconds with 15 in first >>>> >>seconds than 15 as min number is required to avoid undesirable >>>> >>effects >>>> >> >>>> >> >>>> >> Real life example, >>>> >> >>>> >> Login as user (not admin; throttling doesn't apply to Admin) >>>> >> fires about 8 in total. (in less than a second which is the unit >>>> >> we are using in API throttling) >>>> >> >>>> >> Now if this number is set to anything less than this will have >>>> >>unpleasant effect on UI. >>>> >> >>>> >> Including unwanted error (HTML 429) and partial UI screen >>>>rendering. >>>> >> >>>> >> >>>> >> So to hardcode numbers or just document and leave on admins to >>>> >>exercise cautions or ... .. Please provide your suggestions >>>>/inputs. >>>> >> >>>> >> Track it here: >>>>https://issues.apache.org/jira/browse/CLOUDSTACK-1483 >>>> >> >>>> >> >>>> >> Thanks, >>>> >> ...Parth >>>> >> >>>> > >>>> >IMO - people should not be surprised when they upgrade to a new >>>>feature >>>> >release. >>>> >The default should be no throttling. >>>> >We also have to remember that there are other things besides the >>>> >UI that interact with the API. If I were to use Cloudcat or >>>> >knife-cloudstack and provision n-number of nodes, I suspect I'd >>>>rapidly >>>> >find myself throttled/blacklisted. Any sane default that's >>>> >remotely useful for most folks will be awful for high-end sophisticated >>>> >users. >>>> >Adding new functionality that breaks things by default for folks >>>> >is >>>>just a bad >>>> idea. >>>> > >>>> > >>>> >--David >>> >> >
