incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kimbro Staken <ksta...@jumpbox.com>
Subject Re: [libcloud] pricing update thoughts
Date Thu, 03 Jun 2010 06:39:51 GMT
Wasn't the goal here to have a very easy way to update prices? How
many people actually have access to update DNS records at their
company? How about for this project? I guarantee that if you pursue
that path you'll get data that's even more stale than having it
hardcoded in the source. Also if you want providers to help keep that
data current, expecting the person that maintains pricing to have any
kind of access to DNS is just not going to be the case and getting a
DNS change through the internal process of any modestly sized company
can be non-trivial and can take a lot of time. 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?


Kimbro Staken
JumpBox Inc.
http://www.jumpbox.com



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