-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -------- Original Message --------
Subject: RE: [gentoo-dev] Remote Package Building Service
Date: Sat, 8 Jan 2005 16:21:51 +0100
From: Charlie Gehlin <[EMAIL PROTECTED]>
Reply-To: <[EMAIL PROTECTED]>
Organization: Gehlin.Com
To: <[EMAIL PROTECTED]>
Now we are talking! I've spent the last month or so having the same
thoughts, and also a bit of a "solution" that goes further than just
production servers; it also involves user-clients (in our case x86, amd64,
sparc and sparc64). I wish I could tell you that this works flawless today,
but I'm struggling with my [EMAIL PROTECTED] regarding funds, mostly for the
CompileCluster actually. Theese are my thoughts in this matter:
(feel free to forward to list, if appropriate)
*) Profiles:
The servers and client taking advantage of pre-compiled (binary)
gentoo-ebuilds and maybe even kernels(?) are to be placed in profiles,
describing their hardware, like so:
Profile 1 - Server1 , Custom Dual Xeon, 2 GB RAM, Dual Channel 320
SCSI etc etc
Profile 2 - Client1, HP blah blah blah
Profile 3 - Client2, Dell blah blah blah
Profile 4 - Client3, Very old Pentium2 450 MMX, small disk etc etc
Profile 5 - Sun Ultra10 1 GB RAM 8 GB HDD, Creator3D Graphics etc
etc
Now, in my way, I have decided to take advantage of all the really good
things about gentoo, mostly optimizations, and of course, gentoo already
have a way of doing that; the make.conf . Now make.conf (and other things)
are not for the users or server-admins to change, so they are placed on a
central place; the DistServer, and are being mounted by the "clients" at
boot.
The make.conf for Profile 1 is, as you can see, not so very valid for
Profile 2, if you have "tight" optimizations in it (which we plan to do,
right?).
*) DistServer:
Now, the DistServer holds the portage tree, and syncs fairly regular (once a
day?).
The DistServer houses one area of binary packages for every profile that
exists (because it wouldn't be wise to try for example SPARC-packages on a
x86 :)). DistServer also shares the distfiles.
The clients mounts the portage-tree (and having a modified version of emerge
that removes sync-related options), and the profile-specific package-area.
Here comes the nice part; When a portage update is available, the DistServer
has a copy of the profile regarding it's "supposed-to-have" file-system
(takes 2-5 GB/profile if you sort out distfiles, packages and
/var/tmp/portage* right?) and then bind-mounts in the portage and packages-
and distfiles-shares. Then it does the 'emerge -uDv world' (or whatever)
either alone (depending on how many profiles there is) or with the help of a
CompileCluster. The new portage isn't available to the clients until the
DistServer is finished updating _all_ packages in that profile.
Hope you get a grip of what I mean with all this, sometimes I myself don't
:D
*) CompileCluster:
The CompileCluster is only a bunch of machines running distcc, to load off
the DistServer. If you are going to have a lot of profiles (read: if a new
portage is sync:ed and DistServer hasn't finished compiling all the
profiles) there are going to be problems with a compile backlog, DistServer
is never being able to finish due to the package-queue that builds up and
will end up with old packages. Before any compiling is done, the DistServer
orders some environment on the CompileCluster, example; Profile 5 is
actually using unstable ~sparc (set in make.conf) and must therefore order
gcc-config to change to gcc-3.4 and restart distccd(?).
*) Kernels:
The DistServer also compiles/distributes kernels (also defined in the
profiles).
This, of course, requires a reboot of the client to make changes have
effect.
*) etc-update:
This is the really tricky part, to get an automation of etc-update at the
clients, not breaking anything and taking advantage of the fresh software at
the same time.
I have no solution/thoughts on this issue yet :)
*) Installing "Clients":
The DistServer could include TFTP-boot capabilities and/or ISO-images to
burn on CD, making automatic boot:ing, profile selection (including
partitioning and mounting), bootstrapping and 'emerge system'.
*) GentooProductionManager:
How to manage all this? With a web-interface on the DistServer(!)
Not a single line of code written yet :)
These are only my own thoughts on this issue, not to be taken as a real
proposal, and this is probably the way we are going at work (if I get my
funds). Also feel free to fill in misses and ask about anything unclear.
BR
Charlie Gehlin
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFB4SvwUxGWrFYv8KQRApjnAJ0e2p/V36m/waV4hO2mGUHVhK9pnwCfepOR
WPqZn5sVIAEHWuXNuOqSCIc=
=JWgz
-----END PGP SIGNATURE-----
--
[email protected] mailing list
