(Thinking aloud) Priorized defaults

[Michael Tautschnig]

Hi!

> hiya
> 
> >> If FAI isn't told anything, then the result of the installation will
> >> be a SuSE Linux Enterprise Server (SLES) 10 in 64bit. If you tell fai
> >> to install a 32bit machine, then this results in a 32bit SLES. If you
> >> just want a Debian Box, then you'll get Debian Lenny / 64bit. If you
> >> just want a "debian style" box, then this will result in a Ubuntu
> >> 8.04LTS.
> 
> >> Any other ideas?
> 
> > Just use the FAI classes for this. You can write a very intelligent
> > program (or script) that prints a FAI class to stdout, for
> > e.g. UBUNTU08 or SLES10_64.
> 
> Maybe I didn't make myself clear enough. I don't want to address the
> implementation (that part is already done and working very well), but the
> decision-finding. (In the simplest case it's just "Always install OS foo
> in version bar.")
> 

To be honest, Thomas (Neumann), it's still not quite clear to me. What exactly,
i.e., which step of a FAI run, do you mean by "decision-finding"? I'm trying to
detail my questions and thoughts below, but please keep in mind that by no means
I think that FAI is already perfect and that your setup is sub-optimal; you
surely have good reasons that your setup is precisely the way it is at the
moment and we should absolutly seek ways to improve FAI to simplify setups such
as yours. Still, I don't yet understand all details of the problem and would
thus ask for further clarifications.

> 
> 
> On a sidenote: I ~hate~ using classes for this. Mostly because when using
> the default fai scripts and hooks you need a class for every aspect of the
> OS (Linux Flavour, OS Version, architecture) and _also_ quite a lot of
> helper classes.
> 
> Classes I would need:
> 
> "descriptive" classes
> 
> flavour: Debian, Ubuntu, SLES

3 classes.

> version: etch, lenny, squeeze, sid, hardy, 10SP2, 10SP3, 10SP4

+ 8 classes.

> architecture: x86_32, x86_64
> 

+ 2 classes.

Most notably, you need all these classes because they have distinct
requirements. I'm not sure whether you doubt this at all, but anyway: If you
don't use classes, you'll use some other $foo. Anyway, you will have 13 $foos.

> "helper" classes
> 
> DEBcommon (packages that are the same in Ubuntu and Debian)
> DEBIAN_32 (installs linux-kernel-2.6-i686)
> DEBIAN_32-xen (installs linux-kernel-2.6-i686-xen)
> DEBIAN_64 (installs linux-kernel-2.6-amd64)
> DEBIAN_64-xen (installs linux-kernel-2.6-amd64-xen)
> UBUNTU-xen (installs linux-image-2.6-server-xen)
> SLES10 (installs kernel-smp)
> SLES11 (installs kernel-default)
> SLES10_32_VMware (installs kernel-vmipae)
> SLES10_32_VMware (installs kernel-vmi)
> 

Ok. Now these may or may not be necessary (depending whether or not you use the
"and"-patch, as you discussed below). For example, the DEBcommon class can be
replaced by !SLES if you use the "and"-patch, or DEBIAN UBUNTU without the
"and"-patch. But that's a detail. My main point is that you will always need
some $foo that distinguishes these 9-10 different combinations of
hardware/OS/version, unless your mix of distros has something in common.

> and also one BASE_$flavour_$version_$arch class for each installable OS to
> pick up the correct "base.tgz" (Would total in 16 classes currently.)
> 

Because these are different.

> One could also differentiate even further - as of SLES10SP2 zypper has
> become available as an installation tool. Sadly the command line syntax
> has changed between SLES10SP2 and SLES11, so you have to treat both
> zyppers differently.
> 

Still, at this point you only need to distinguish SLES10SP2 and SLES11, you need
not care about $arch, $flavour, etc.

> 
> Using the "and"-patch for install_packages has lessend the number of
> "helper"-classes quite considerably, but I still found it necessary to
> rewrite/extend the following hooks: configure, debconf, extrbase,
> instsoft, partition, prepareapt, updatebase.
> 

I might be lacking the necessary creativity to see a solution, but to me it
seems that you do have all those different aspects and you need to tell FAI
about this. Therefore you need some $foo that describes those aspects. Within
FAI that is called a class.

Regarding the huge number of hooks: I'd really think that these should _not_ be
necessary and instead be patched in mainline. Maybe some of hooks are necessary
because you do multi-distro, but the new FAI website broadly claims that it
supports a large number of distros, so it should better really do so.

Best,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20091210/308933bc/attachment.bin