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
