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
