Future of FAI (fwd)

[AUSTIN MURPHY]

On Fri, 22 Nov 2002, Niall Young wrote:

> On Fri, 22 Nov 2002, AUSTIN MURPHY wrote:
>
> > I was thinking of a single "spec" file to define each class with an
> > associated tarball containing all related scripts and files.
>
> > # scripts (location)
> > /fai/scripts/GNOME/S01
> > /fai/scripts/GNOME/S03
>
> Sounds great, but do we need a separate spec file?  I like the ease
> of customising classes simply by dropping SXX scripts etc. in place and
> have them automatically detected instead of hardcoding them in, this
> keeps it flexible and modular.  I'd just separate everything from
> /usr/local/share/fai/* into /usr/local/share/fai/CLASS/* with each file named
> appropriately: disk_config package_config/ scripts/ etc.  It's then an
> isolated tree, and you could add tarball support later by just detecting
> CLASS/ or CLASS.tar.gz

You make a good point about dropping-in scripts etc.

The idea of having separate disk_config/, package_config/, scripts/ etc.
directories solves the problem of not knowing exactly what class has which
sub-sections but it adds a whole lot more sub-directories than the already
large number that currently exist.  This is especially true under the
fai/files/ directory.

The key ideas behind my spec file were to:
1) allow easy recursive dependencies
2) easily see what a class does
3) reduce the number of files and directories

As to #1.  This doesn't exist now, but seems easy enough to implement.
Once implemented I think this will simplify the initial class definition
scripts.

As to #3.  Most of my classes have an associated CLASS.var file as well as
a CLASS file for packages.  My goal was to combine these 2 into a single
class spec file that also included the list of scripts, hooks, and files
associated with the class to solve #2.

Your directory concept solves #2 very well.  I don't think it addresses #3
and or #1.

I don't propose to change the way FAI executes scripts or hooks nor do I
want to change the behavior of fcopy/ftar.  If a script was added and the
spec file was not changed, I think it FAI should run as it is expected to
run now (with the new script, regardless of what the spec file says).

I am thinking along the lines of a Linux package manager.  A package is
installed with all it's dependencies met and then you can do anything to
the files once they are installed.  It might even be possible/practical to
convert each class-pkg into a uDeb or something.  (Just an idea)

I'm afraid that changing the directory structure would lead to a
considerable amount of work in reorienting each part of FAI that "knows"
the current structure.

Does this make sense, or am I way offbase?


Austin Murphy
----
Systems Programmer
Rutgers University