incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Solomon Hykes <solo...@dotcloud.com>
Subject Re: [libcloud] pricing update thoughts
Date Thu, 03 Jun 2010 06:58:48 GMT
On Wed, Jun 2, 2010 at 11:39 PM, Kimbro Staken <kstaken@jumpbox.com> wrote:

> [...] expecting the person that maintains pricing to have any
> kind of access to DNS is just not going to be the case [...]

DNS record would be updated from a single location, every time new
code is pushed to the main repo. So the workflow remains the same:
committers push code with new pricing information.

> Also if you can't get
> the ASF to deliver a static file from an HTTP server, what makes you
> think that getting them to add stuff to DNS will be easy?

Paul's message led me to believe that the ASF needed alternatives to
simply hosting a static file on a public HTTP server. If that's not
the case, obviously there's no need for anything fancy. If, on the
other hand, the kind of traffic generated by a great number of
libcloud clients continuously polling for new pricing information is
actually a problem for ASF's infrastructure, even with http caching
(think many tcp connections), then DNS might be a viable alternative.
I am not familiar with the ASF infrastructure, so I can't answer that.

I think we are among grown-up engineers and all understand that the
simpler the tool, the better.

Best,
Solomon

> On Wed, Jun 2, 2010 at 9:58 PM, Alex Polvi <polvi@cloudkick.com> wrote:
>> On Thu, Jun 3, 2010 at 4:39 AM, Jerry Chen <jerry@apache.org> wrote:
>>>
>>> On Jun 2, 2010, at 11:34 PM, Solomon Hykes wrote:
>>>
>>>> On Wed, Jun 2, 2010 at 9:24 PM, Dan Di Spaltro <dan@cloudkick.com>
wrote:
>>>>> I don't know enough about the DNS protocol, but are there limitations.
 This
>>>>> seems like a weird way to do it... Are we just doing it to be novel,
or I
>>>>> don't see why a typical webserver serving JSON (pretty well tested) set
up
>>>>> isn't good enough.
>>>>
>>>> The 2 things you get for free with DNS are 1. caching and 2. virtually
>>>> unlimited scalability.
>>>>
>>>> I would evaluate how much work and money would be spent on
>>>> implementing a cache system in libcloud and hosting a json file
>>>> reliably. Depending on the answer, using DNS will make sense or not.
>>>> Definitely no point in doing it for the sake of novelty.
>>>
>>> To add to that, this is how I understand this approach in general:
>>>
>>> * Pros for DNS
>>> ** Stable
>>> ** Existing infrastructure
>>> ** Replication/caching is "free"
>>> ** Trust/validity (ownership of domain)
>>> ** Lends to discovery
>>>
>>> * Cons for DNS
>>> ** Propagation delay/limitation
>>> ** Records have a finite length limitation, e.g. SPF needs indirection
>>> ** Different protocol than Provider APIs (DNS v. HTTP)
>>> ** Discovery not usually needed, as a lot of other things are already hard-coded,
viz. URL endpoints
>>> ** Non-core library or additional module needed for DNS TXT queries
>>
>> To be fair....
>>
>> * Pros for JSON
>> ** Supported by any language (normally w/out additional dependencies)
>> ** Behaves like the cloud providers themselves do
>> ** Caters to web developers, the likely candidate for people actually
>> building on this stuff
>> ** Human readable with nothing more than curl/browser
>> ** KISS
>>
>> * Cons for JSON
>> ** We have to run a static webserver (wait, that's not hard at all and
>> can just use S3)
>> ** Caching (again, it's a static file, so this is not a problem)
>>
>> I'm not convinced at all that we should complicate things with DNS.
>>
>> -Alex
>>
>> --
>> co-founder, cloudkick.com
>> twitter.com/cloudkick
>> echo V2UgYXJlIGhpcmluZyEK | openssl base64 -d
>>
>

Mime
View raw message