Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Parth.Jagirdar@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Parth Jagirdar <Parth.Jagirdar@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Subject: RE: [DISCUSS} API Throttling minimum number of calls per unit of
 time
Thread-Topic: [DISCUSS} API Throttling minimum number of calls per unit of
 time
Thread-Index: 
 Ac4WzOJilSSDGeljQrW4IbMS9TvdpgALS8GAAAc2+nD//+J8AIAAFcIAgAAC04CABb+3gP/8ziaggAbEhoCAAFM9YA==
Date: Fri, 8 Mar 2013 00:36:53 +0000
Message-ID: <8C261DB050CCFF47A271694F522ECF94F13A94@FTLPEX01CL01.citrite.net>
References: <8C261DB050CCFF47A271694F522ECF94F13740@FTLPEX01CL01.citrite.net>
 <CD5E701C.BE52%min.chen@citrix.com>
In-Reply-To: <CD5E701C.BE52%min.chen@citrix.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 "V=
iew 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 r=
ight 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.chen@citrix.com]=20
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 t=
ime

Hi Parth,

	I don't understand the issue here. After you reach the maximum number of A=
PIs you set, for every API issued after that point and before interval wind=
ow expires, backend will have to throw user an error, what is the issue her=
e?

	Thanks
	-min

On 3/7/13 3:41 PM, "Parth Jagirdar" <Parth.Jagirdar@citrix.com> wrote:

>Refer to
>
>CLOUDSTACK-1586
>
>I think minimum number to throttle and  "API Throttled : ERROR" which=20
>has
>1:1 ratio, also needs to be addressed somehow.
>
>Thanks,
>.. Parth
>
>Thanks,
>.. Parth
>
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@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=20
>of time
>
>This issue has been fixed in both 4.1 and master. A new global setting=20
>"api.throttling.enabled" is introduced.
>By default, it is set to false, so no API throttling is enabled. To=20
>enable it, just change the setting to true, and restart MS. FS is also=20
>updated with this information.
>
>Thanks
>-min
>
>On 3/1/13 6:06 PM, "Min Chen" <min.chen@citrix.com> wrote:
>
>>Thanks Alex for clarification. I will provide an extra global setting=20
>>to allow user to easily enable/disable this instead of going through=20
>>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.Huang@citrix.com> wrote:
>>
>>>This is something that everyone writing plugins should think about.
>>>
>>>A component being enabled does not automatically mean that=20
>>>functionality being enabled.  Here, API Throttling component is=20
>>>enabled/disabled through componentcontext.xml  but the behavior of=20
>>>whether it should automatically default to setting a limit on api=20
>>>calls is a property of the api throttling component and should not=20
>>>depend on api throttling component being enabled/disabled to set that=20
>>>limit.
>>>
>>>It's a tricky problem to see because the distinction seems to be so=20
>>>small.  You have to look at it from the perspective of the people who=20
>>>touches cloudstack's code.
>>>
>>>One type of people is the distributor of CloudStack code.  He comes=20
>>>in and says I understand CloudStack and I pick the best components to=20
>>>deploy it with.  For example, they may choose to put in a different=20
>>>api throttling component to package.  He's the person who changes=20
>>>componentContext.xml.
>>>
>>>Another type of people is the deployer of CloudStack code, usually a=20
>>>system admin.  He takes the package from distributor and says I read=20
>>>the documentation and I understand how to use your cloudstack  as a=20
>>>package.
>>>He's the person who configures CloudStack through configuration=20
>>>variables.
>>>
>>>Sometimes, these two people are the same person but when we write=20
>>>code we have to think of them as separate people.  Therefore, api=20
>>>throttling component should default to not limiting api calls should=20
>>>not rely on the api throttling component being disabled in=20
>>>componentscontext.xml to achieve that functionality.  That's=20
>>>functionality that belongs to api throttling after it is enabled.
>>>
>>>Just think of the case of the deployer upgrading.  The distributor=20
>>>decided they want to add this functionality to the release but why=20
>>>should the deployer know that he should disable api throttling in=20
>>>componentscontext.xml?
>>>
>>>--Alex
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Min Chen [mailto:min.chen@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=20
>>>>unit of  time
>>>>=20
>>>> Currently for 4.1 api throttling is enabled by default since we=20
>>>>include that  pluggable service in ComponentContext.xml. Parth,=20
>>>>please file a defect for  that, I will fix it.
>>>>=20
>>>> Thanks
>>>> -min
>>>>=20
>>>> On 3/1/13 4:36 PM, "Parth Jagirdar" <Parth.Jagirdar@citrix.com> wrote:
>>>>=20
>>>> >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:david@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=20
>>>> >unit of time
>>>> >
>>>> >On Fri, Mar 1, 2013 at 5:34 PM, Parth Jagirdar=20
>>>> ><Parth.Jagirdar@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=20
>>>> >>"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=20
>>>> >>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=20
>>>> >>as min number is safe. Or even 8 if we have decent idea of=20
>>>> >>intervals they get fired at..
>>>> >> But for action Y that fires 20 in 2 seconds with 15 in first=20
>>>> >>seconds than 15 as min number is required to avoid undesirable=20
>>>> >>effects
>>>> >>
>>>> >>
>>>> >> Real life example,
>>>> >>
>>>> >> Login as user (not admin; throttling doesn't apply to Admin)=20
>>>> >> fires about 8 in total. (in less than a second which is the unit=20
>>>> >> we are using in API throttling)
>>>> >>
>>>> >> Now if this number is set to anything less than this will have=20
>>>> >>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=20
>>>> >>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=20
>>>> >UI that interact with the API. If I were to use Cloudcat  or=20
>>>> >knife-cloudstack and provision n-number of nodes, I suspect I'd
>>>>rapidly
>>>> >find myself throttled/blacklisted. Any sane default that's=20
>>>> >remotely useful for most folks will be awful for high-end sophisticat=
ed users.
>>>> >Adding new functionality that breaks things by default for folks=20
>>>> >is
>>>>just a bad
>>>> idea.
>>>> >
>>>> >
>>>> >--David
>>>
>>
>