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 >
