(Thinking aloud) Priorized defaults

[Thomas Neumann]

hiya

> 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"?

Originally I was just talking about stuff happening inside "class/".

<eliding half a page of explanation just to describe the current situation>

I think I'm letting this idea rest at this point. People started to
discuss the actual handling and installation of different OS with the same
fai-config, which I think is a bit more useful to this list then some
"esoteric" feature concerning probably just our environment.

> 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.

> 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.

> 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.

Nevertheless the first assumption is wrong. DEBcommon can not be replaced
with !SLES, because that would also include every future distribution that
is not SLES - e.g. RedHat.

But let's not get to deep into this. It's just 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.

At the current state: Yes. You are right.

In my view this has a lot to do with the fact, that these so called
"classes" are nothing more then pretentious switches. If these were
real "classes" then one could create a relationships between them.
By specifying "hardy" and "x86_32" the OS is described well enough
to start the installation. Must be hardy, must be ubuntu, must apply all
common options between debian and ubuntu and must use the base image for a
32bit Ubuntu hardy bootstrap.

>> 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.

Yes. But totally redundant if OS flavour, version and architecture have
already been specified.

>> 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.

Actually I don't want to care at all. FAI does a pretty good job of
abstracting package installation away. What I really want to do is some
highlevel "use this package repository" and not really care if the line is
written to sources.list,  configured as a new repo via yast, zypper or
whatever the config tool for redhat is called.

(Of course I have to make sure to provide a debian repository to a debian
box.)

>> 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.

Yes I do. But I don't need to specify all of these aspect over and over
and over again.

If "SLES" and "10SP2" is specified, then that also automatically includes
"SLES10". If "SLES", "10SP2" and "X86_32" is specified, then that
automatically includes all necessary information to choose the correct
base image.

> Within FAI that is called a class.

I don't care what it is called. At least half of my classes are redundant.

I started to replace classes with variables. That way I have better
options to use them in a sensible matter.

> 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.

I'm doing some weird things that maybe shouldn't really be included in
mainline at all. Other stuff may be interesting (like fetching base images
from a webserver instead of basefiles/ or using a template mechanism to
customise disk_layout files).

tschüß
thomas