From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 01 Oct 2003 - 01:21:36 BST

Dear VServer Community!

first, thanks for the positive feedback!
one can dream, but many can accomplish ...

As promised, here is a description what I
had in mind for the (nightly) automated
vserver kernel build/test ...

a short version of possible benefits:

 - all-in-one patches for all possible
   scenarios ...
 - regression tests and error reports
 - automated rediffing (dream on ;)
 - automated testing (it does/not boot ;)
 - performance values

how to do ...

setup a space, large enough to hold (linked)
copies of 2-3 kernel versions (2.4.20, 2.4.21,
2.4.22) and the recent pre/rc versions (pre1-
pre5) in variations of all 'useful' vserver
kernel enhancements/patches (mq, cx, cq, ml,
dl, vr, rmap, xy, yz) so that those are
available for build/testing and compile them
with different setups/configs probably for
the most common architectures, to produce a
large set of patches, together with an error
log documenting the build process ...

In the second stage those kernels could be
fed into an automated testing (with QEMU for
example) to verify basic functionality, again
producing reports on any failure ...

this would allow to concentrate on real kernel
development instead of rediffing patches over
and over again ...

Now for the machine/disk requirements:
I tried this once on a 40GB space and it
wasn't nearly enough ...

A 2.4 kernel in dormant state uses ~180MB disk
space, a 2.6 kernel ~220MB .. on build this is
around 300-400MB depending on the configuration,
if you keep 5 kernels in built state for 5-6
patches each, you are at 15GB just for one
architecture, and of course we want to do cross
compile tests too ;)

you can reduce the actual usage by building
only those kernels you want to test, but this
adds great overhead as kernel builds are slow
and requires some good scripting (which means,
it has to be done by someone ;)

everything speeding up the build/test process
would be advantageous, so huge amounts of RAM
(for buffering) and powerful CPU's are welcome,
but some kind of distributed system would be
a good solution too, again it just needs someone
to look after it ...

of course all this can be done inside one or
more vservers, without any issues, but I guess
the testing would require loop and network
access to setup QEMU harddisk space, etc ...

best,
Herbert