Re: [gentoo-server] Wrapping my brain around a gold server.

[Dormando]

> There always is legacy.
>
> That fact has been a touch absent in these discussions. If we're really
> smart, we won't just create a gentoo-gold-server which is only suitable
> for use in networks of gentoo machines, we'll create a master server
> which runs gentoo and which is suitable to act as gold server for a
> whole suite of machines, regardless of OS.
>

Excellent. Paying attention to legacy means less work for myself; I would
have to support some of this crap anyway. There are probably dozens of
cases where large companies are running programs they don't even have the
source code for anymore! Making these legacy systems at very least
manageable should be an early goal. I cannot imagine something like this
getting popular without that kind of edge into a existing networks.

Like the bootstrapping doc says (I'm going to finish reading this site
again on the ferry to work tomorrow...), we can get configs into
versioning systems for any architecture. Packaging is icing on the cake.
If I can get my sunboxes to accept updates (depending on what version
they're running) for security fixes from my gold server, as well as having
my redhat 6.2 boxes pull in a few extra perl modules... That's
flexibility for you.

Generally, the architecture would benefit from allowing a lazy-caching
system for the different OS/hardware classes, with the usual set of
options. Max cache size, time-to-live, and even an option to mask packages
to never expire unless a newer version is available. The old sun and linux
2.2 machines might not get upgrades very often, but you could be launching
5+ newer gentoo (or debian) servers a week, and can't be stuck downloading
when an upgrade to a legacy system pushed your packages out of cache.

But this is all getting into details I'm not sure we're ready to pass yet.
The focus of my meager extra ounces of brainpower is toward this class
tree idea, and how to get even more basic basics down (tools and docs for
getting gold-server CVS, and example scripts/tools/docs for many
OS's/distributions for config pull clients).

As far as packages...
Hardware, OS, software, ? - Three classes in total, as you said? It's easy
enough to see where they cross, and how they might be organized.

There're quite a few ways of thinking about this, but my only personal
requirements are in simplicity and elegance. Our gold servers need to
maintain systems from years back to now, but also need to be able to
change hands... I'd be sad if I spent months getting something like this
going at work, then half the staff changes over and they start building
new servers outside of the gold's control, since they don't have the time
to learn how to manipulate it.

-Dormando