Configspace redesign proposal

Concept for a new FAI configspace and class hierarchy

proposal

To make sharing of classes easier, I want to propose an alternative structure of the FAI_CONFIGSPACE.

Currently, if you want to get "everything that belongs to a class", you need to look into many differentr directories, use find and grep.

In my proposed design, everything that belongs to a class is contained in one directory. Still, there could be interdependencies between classes, e.g., the class "MUSICPLAYER" installs a graphical program if the class "GUI" is also defined, and this proposal doesn't have a solution on how to bind these together (excect adding some metdata like "influenced-by" -. similiar to the depends thing)

but the fact that this proposal doesn#t solve all problems

The basic idea looks like this:

1. CLASSNAME/
   1. class_scripts/ -> (1)
      1. <NR>[-NAME]
   2. variables -> (2)
   3. package_config -> (3)
   4. disk_config (4)
   5. debconf (5) a debconf file for that class
   6. README (6)
   7. hooks/ (7)
      1. <TASKNAME>
      2. <TASKNAME>
   8. depends(8)
   9. scripts/ (9)
      1. <NR>[-NAME]
      2. <NR>[-NAME]
   10. version
   11. files
   12. /path/to/file/filename

And here the explanations:

1. The name of the class
   1. the classic class directory
      1. a script which migh automate the definition of this class implicitly
   2. a file containing what was before class/CLASSNAME.var
   3. a file describing packages to be installed for this class
   4. a file that was before: disk_config/CLASSNAME
   5. a debconf preseeding file for that class (how is defined which debconf presseding file overwrites which other one? (Mrfai: this is defined by the order of the classes)
   6. an (optional) file containing some info what this class is about
   7. the classic hooks directory, only that the files inside don't need the classname added again.
      1. a hook for the task <TASKNAME>
   8. a file with a list of classes this class depends on
   9. the classic scripts directory, only there are no extra subdirectories and the CLASSNAME doesn't appear again here.
   10. (optional)file with a version string inside
   11. The directory with files for that class. As this contains only files for

exactly this class, it's not necessary anymore to name the final file after the class name.

This is just a rough idea, I think will try to make an example implementation some day 'cause I like to see how it "feels"  :)

What do you think? Anything wrong or good with that?

comments and answers to be discussed

1. comment from Michael Tautschnig about the dir CLASSNAME/class: do we really still need this directory? For this kind of structuring, you need to have the classes defined already
   1. reply from me: hmm, as i moved the variables to an extra file, you are right, I think. I still keep it there now and see if I can really keep it empty in a reference imlementation, then I'll throw it away)
   2. later comment from HS: I get an idea about the class directory now: in the good old "class" directory, even in the new architecture, all scripts are located in a central directory which decides class definition, according to hardware, hostnames, disk sizes, as usual. If you install a new class into the "class repository" containing my proposed hierarchy, you also need to add something in the class directory, which defines the class for some machines.
2. comment from MT about depends: A great idea, but IMHO hard to implement - how would you deal with those dependencies, what would they mean to FAI? We'd need to take care of recursive dependencies!
   1. reply from HS: we could say that we only solve depends one (or some other number) level deep - so, when "GNOME-DESKTOP" is a class defined directly for an install client, and this depends on "XFREE", it's solved. When "GRAPHICAL_DIFF" depends on GNOME-DESKTOP, the XFREE isn't solved anymore. I think, this can better be answered when having a reference implementation. And, it can be left out in the first place, because it adds functionality we don't have now and probably don't really need. Also, we could try tracking dependency paths and check for cycles - this is a bit too hard probably.
3. comment from Juergen Kahnert(JK) about the goal of this proposal and the
4. level we reach it: The goal is ok, I'm not sure if this is the best way reaching it. For example, did you never used "if ifclass ..." at your scripts? Or did you never used "package install <class>" at your package configs? How to easily rename a class which uses those features? Maybe we need a class-management-system, some tools doing things like installing, removing, renaming, ... classes or at least helping by doing those tasks.
   1. reply from me: right, this proposal doesn't solve all things, but I think it makes at least some things easier. I don't use a lot "ifclass" myself - for people who do, it will not help much in renaming classes, that is right.
5. comment from Michael Tautschnig about the package_config, which was a file in the first draft: let's make this a directory, containing files named like <NR>[-NAME] so we solve the problem of some users to enforce an installation order for some packages
   1. reply from JK: this isn#t needed and in some cases problematic - see the

full thread below.

1. Mrfai: Since class dependencies are not part of FAI yet, "depends" should be optional. IMO FAI is not reponsible for sopporting class dependencies. FAI just supports calling scripts (that define classes).

see further comments: http://www.mail-archive.com/linux-fai-devel@rrz.uni-koeln.de/msg00208.html

comments that went into the proposal

1. comment from MT: README should be optional, although it's pretty useful
2. comment from MT about version string file: useful., but should be optional
3. comment from MT: what about the files directory?

details on handling class dependencies

I just had some more thoughts about how to handle class dependencies. These are my ideas about this:

• With the new cleaner design, classes can be packages as deb's. here, we (or users building their own class debs) can just use the debian dependencies, which are great to determine if a class must have another class, or can optionally use stuff from another class/be influenced by another class
• still, at class definition time, these dependencies need to be checked also. So, what do we do?
  • we will still have something like the old "class" dir, where we place files named by hostname, and things like the 50-host-classes script
  • This directory will be read by some script I call not the "class definition parser"
  • So, this parser reads this directory and will end up with some list of classes, printed by reading a file called hostname, and/or running 50-host-classe
  • now, it will check if the now defined classes have additional dependencies
  • it will therefore look into each depends file (as mentioned above in the design)
  • classes mentioned in this file which are already in the FAI_CLASSES list are ignored, they are already there. I think this is all we need to get rid of dependency cycles (or do I get something wrong)?!
  • if a new class is found, it is added to the FAI_CLASSES list. Sure, this class, too, muss be checked for it's dependencies.
  • Clearly, it is possible that admins could define long chains of dependencies if they don't work cleanly. We could, if we want to, define some mx dependency chain deepness level and stop after checking the third level of depends. I am not sure if we really need this.
• Interesting add-on:
  • we could have must and should depends!
  • shoudl depends: if a should class is available, it is additionally defined. If not, an info message/warning is printed into the log, but installation continues normally
  • must: if a must dependency is not fullfilled for some reason (e.g. a must class simply is'nt available), an error is printed and installation is stopped. (for example, Class PHPMYADMIN depends on having WEBSERVER, otherwise it is not useful, and installation should not waste further time until the admin either removes the PHPMYADMIN class or adds the WEBSERVER class to have it available in ths configspace)

Mrfai's proposal

• new layout of config space. This proposal is identical to henning's in most parts. Different is the handling of files and class directory

• class/.... (same as before, without *.var files)
  • classes itself should not define which hosts will belong to them
  • a seperated process (using scripts in class/) will do the assignement of classes to hosts

 CLASSNAME/README (description)
 CLASSNAME/variables (was CLASS.var)
 CLASSNAME/disk_config
 CLASSNAME/debconf
 CLASSNAME/package_config
 CLASSNAME/hook.partition
 CLASSNAME/hook.instsoft
 
 CLASSNAME/10-miscname
 CLASSNAME/30-miscname
  or
 CLASSNAME/scripts/10-miscname
 CLASSNAME/scripts/32-miscname

• files/.../.../CLASSNAME/ (same as before) This is better, since we only need one mode preinst and postinst script.
  • Where to put preinst, postinst, file-mode files, when files.../ is not a directory?
  • preinst, postinst, file-mode are normally shared among multiple classes