Re: goals for next release
On Fri, Jan 30, 2004 at 04:29:33PM +0100, Steinar H. Gunderson wrote:
> On Fri, Jan 30, 2004 at 02:58:41PM +1000, Andrew Pollock wrote:
> > From my experience, what I believe the automated installs in d-i to do (not
> > having seen it done or tested it yet), it's not going to scratch the surface
> > of the functionality that FAI does, and FAI pisses all over KickStart for
> > flexibility (with the appropriate increase in learning curve and
> > complexity).
>
> Well, could you please elaborate a bit on what FAI could do that d-i will not
> be able to do? (Ie. some sort of "requested feature list". :-) ) Also, will
> FAI work for sid at all? (I can only find references to woody in the
> documentation.)
I don't see the value in trying to make d-i be FAI, but here's some more
info...
FAI uses classes. These classes are used throughout the decision making
process for configuration, package installation, etc. I liken it to allowing
you make your Linux build process a jigsaw puzzle or a Lego toy. You can
break down the components of what makes your installed system into
components and assemble them how you wish.
To give you a specific example, where I work, we have an Internet gateway.
We have boxes that act as proxy servers, mail and DNS servers, NTP servers
etc etc.
I can specify a combination of classes for a particular installation to suit
what that box's function is going to be, and where it will sit on the
network for example, and FAI will install the relevant groups of packages I
have predefined, and copy appropriate /etc/hosts, /etc/resolv.conf,
/etc/ntp.conf (you get the idea) files appropriate for that particular
class.
FAI boils down to allowing you to manage a whole infrastructure. I'm just
using it in one particular way, there would be many other ways than what
I've described. FAI relies on a central (NFS) server to house all the FAI
specific configuration, which is uses during the initial boot that performs
the installation, whereas d-i would have a pre-made (more flat, ala
KickStart) configuration, which is more like an unattended install than
something modular.
> > I think d-i automated installs and FAI will both have their place, going
> > forward, for different reasons. d-i may be good for a bare-metal recovery of
> > an existing installation, whereas FAI is probably going to be better at
> > deploying new installations on inconsistent hardware (I use it to run up
> > infrastructure servers, on random hardware).
>
> Hm? Why shouldn't d-i be able to handle inconsistent hardware? I mean, we
> have discover and autopartkit; what else should touch hardware too much?
True. I think what I was trying to say was I can have an install and all the
appropriate class stuff setup such that I can have a proxy server built on a
Dell 1650, which uses SCSI disks and an Intel EtherExpress NIC, or an IBM
xSeries, which uses IDE disks and a Broadcom chipset, and I don't have to
use discover in the end result, just during the initial FAI stage, and FAI
determines which NIC I have and aliases eth0 appropriately.
FWIW, I'm not a big fan of running discover all the time. I find the crap is
spits out on bootup quite gross, and I think it would be disturbing for some
inexperienced users. It would be better if discover ran once during
installation, and added appropriate module aliases based on what it
discovered...
Just my 0.02 dollars worth...
Andrew
Reply to: