[Support-admins] Change proposal regarding the Rubyforge distribution infrastructure - your input is needed
tom at infoether.com
Wed Nov 14 09:56:49 EST 2007
On Mon, 2007-11-12 at 21:38 +0100, Dennis Oelkers wrote:
> Hello rubyforge, hello rubycentral,
> For those of you who do not know me: I am the current "maintainer" of
> the general mirroring architecture of rubyforge, running the master
> mirror and the infrastructure to push out the changes of the gems and
> rubyforge files repositories to all the subscribed mirrors.
> I am currently living in Berlin, Germany, where I study computer
> sciences (starting my diploma thesis in about a year), and working for
> Nokia Germany.
> In our constant efforts to improve the quality of rubyforge, we had to
> struggle with several crashes of the main (now retired) server hosting
> the website and the project repositories. At that time, we noticed that
> the webserver is a crucial component of the distribution chain, because
> all clients have to contact the main server via http, and are
> distributed to the different mirrors by following the redirect which is
> then issued.
> Although the current hardware is running fine so far, we would like to
> change this in the long run. The current idea is to transfer the load
> balancing to dns, and maintain the dns entries using a modified version
> of the script which is currently generating the apache rewrite map.
> This is all fine, but has one big drawback: We are not able to do
> centraslised accouting of the downloads, like we are with the current
> solution. Gathering the logfiles from the different mirrors is a
> solution which seems to be too painful to do at the moment. Abstaining
> from the statistics we are able to generate from the centralised
> logfiles we currently have, is not an option either.
> This is the main reason why I wrote this mail: what is your opinion
> about the general proposal? Do you have a clever idea to solve the
> logging problem? Is there anything else that you see as a
> problem/improvable point of the current rubyforge infrastructure?
Another option might be to ensure the gem index is being sync'd out to
all the mirrors... that would let people do things like this when
RubyForge is down:
gem install ikko --source http://rubyforge.vm.bytemark.co.uk/
Hm, I just tried that and it worked... maybe we're doing this already?
Of course, people would still have to know the proper URL for the gem
More information about the Support-admins