[Savannah-hackers-public] [gnu.org #337760] [sr #105912] Home page upload broken?

[Justin Baugh via RT]

> I don't think it is a good idea to move services to Savannah while it
> is already a loaded computer.

We must have different definitions for loaded.

Savannah's load is trivial, considering it's a quad Xeon.
Over the last year, measured by our cacti instance, the 5 minute 
load average is < 2.0. Over the last few months, that drops to 
0.96. In addition, iostat seems to suggest that the disk
subsystem is under 10% utilization. And with over 1gb of ram
inactive it's not pressed for memory. 

Not only that, but nongnu.org is static web content. It is unlikely
that the addition of this would have any noticeable effect on 
Savannah's performance profile at all.

I don't want to press the issue. If you don't want to do this, or
don't see the utility in it, it can simply stay where it is now, and
everyone agrees that the current system needs to be improved.

> Note that nongnu.org is quite simple since all accounts are dealt with
> the same way (nongnu.org/* and *.nongnu.org).

Agreed.
 
> gnu.org however is much more complicated because every project may be
> replicated at a different point of the hierarchy (software/, /,
> translation projects, education/, and other exceptions).
> gnu.org is probably where improvements are needed the most.

What improvements, in your mind, should be made? There are a number of 
potential improvements that come to my mind...

As for what has been done, all the scripts involved in the process 
(cron jobs, new project creation script) now do comprehensive 
logging and check to make sure that they are not stomping on each
other (the latter was an improvement made a long while ago). Debugging
any problems should be much easier. Indeed, several were exclusively
related to the migration to Apache 2.0, and shouldn't reoccur.

One thing I noticed is that scripts that are called from Savannah
return nothing in the way of output. A possibility is to actually 
return a status code and message - either that, or an XMLRPC interface 
to replace the given system could be designed, which would actually
return any useful information including error messages, and also allow
a variety of useful operations (re-checkout a project from scratch, 
make a new project, update a project, etc).

There's no real reason on our end why we can't do on-commit updating
now. I'm willing to spend the time getting it done, along with any
other improvements you want made.

-Justin


-- 
Justin Baugh (baughj at gnu dot org)
Systems Administrator
Free Software Foundation