incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [libcloud] pricing update thoughts
Date Thu, 03 Jun 2010 10:44:34 GMT
On Wed, 2010-06-02 at 23:39 -0700, Kimbro Staken wrote: 
> 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?

Interesting perspective.

Some thoughts/questions:

Who is going to be responsible for maintaining this? Is this going to be
done on the Apache side or on the provider side?

If it is done on the Apache side, which group of people will need access
in order to do it? Certainly Paul could edit DNS TXT records, but would
it be possible/feasible to grant write access to other libcloud
committers to just that small portion of the DNS setup without giving
over control to, e.g. libcloud.apache.org?

If we were to go to http, how would we prevent libcloud from downloading
this data on every method invocation? This has been an issue in the past
at the ASF, where code pulls from Apache servers every time it is
invoked (in that case it was pulling a DTD every time it parsed some XML
that referenced the DTD!!). Libcloud doesn't have any caching mechanisms
or data storage mechanisms that I am aware of at present, and I'd
imagine that in many circumstances libcloud doesn't stay resident in
memory for long enough for simply store it in memory to give sufficient
caching.

It'll probably turn out that the best place to keep it all is in
Subversion :-P

Upayavira







Mime
View raw message