whirr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adr...@jclouds.org>
Subject Re: JClouds & OpenStack throttling
Date Wed, 14 Nov 2012 22:28:10 GMT
On Wed, Nov 14, 2012 at 2:20 PM, Steve Loughran <stevel@hortonworks.com> wrote:
> On 14 November 2012 22:16, Adrian Cole <adrian@jclouds.org> wrote:
>> Hi, Steve.
>> This low throttling policy is not an OpenStack limitation, this is a
>> Rackspace limitation.  For example, OpenStack does define the error
>> codes, but there's nothing in the code that says request count for a
>> public cloud service needs to be so low, that it will lock out any
>> high frequency poll attempts.
>> There's a couple things to do, conceding this.
>> 1. contact rackspace and raise your limit
>> 2. set the poll interval high like in everett's example, which I think
>> was 30 seconds.  You won't know for a while if the server started or
>> died, but at least you won't lockout your account.
>> 3. there's an effort to reduce the amount of calls in jclouds by
>> batching requests together and then using a single network call for
>> many machines.  This still won't solve rackspace as it would likely
>> also exceed the limit, but it would foster the same number of calls
>> for a single node cluster as a 20 one.  You can join jcloud-dev google
>> group if you want in on this.
> I may soon do that.
you will be very welcome :)
>> Above all, please complain to rackspace.  Quotas that are set this low
>> without a viable alternative place undue burden on the ecosystem.  I'd
>> understand it, if they had a streaming api, but they don't and the
>> only way to tell if your servers are running are to poll them (or
>> switch to IP related pings I guess).
>> HTH,
>> -A
> Is it the polling that's doing it, not the instantiation requests? That's
> easier to deal with.
well one leads to another :)  there's also an issue on rax where 500
error actually creates a server before sending the error code, which
can leak vms :)  This relates to your finding that rate limiting
response can be sent after successful processing.  In either case, we
could implement some "double-check" to see if the response was really
an error or not.  The bad part is that generally the password is only
sent in the create response, so even if the VM was created, you
probably can't use it unless you are using ssh keys.
> I've been playing with another Nova service, but it had different "issues".
I hear ya

View raw message