On Thu, Jun 3, 2010 at 3:44 AM, Upayavira <[email protected]> wrote: > 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?
Committers. They would update a dict in trunk. This would get sync'ed automatically to wherever we store it: DNS or HTTP. > 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? er, all we would do, is make a python tool that generates a pricing DNS zone. Then we would for example, delegate the pricing.libcloud.apache.org DNS name to a separate set of DNS servers, like say libcloud.jails.apache.org and a few volunteer slaves. For commiters, they would just commit the updated pricing infomation to trunk, and we could automate the rest of the chain. This is relatively similar to what Spam Assassin does with some of their zones used for spam. > 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. Yes, this is the specific example of why with the ASF Infrastructure Hat on, I have doubts about hosting it over HTTP, mostly because we have been burned in the past by projects who don't know about caching, and were downloading the same freaking XML files hundreds of times per second from the same IP address.
