Testing changes in FAI

[Jens Dreger]

Hi Paul!

On Tue, Sep 19, 2006 at 10:34:26PM -0400, Paul Lussier wrote:
> I've inherited a legacy FAI configuration.  Currently it's running FAI
> 2.8.4.  We're thinking of upgrading to 2.10.x at some point, but
> before that we need to completely understand everything that FAI is
> currently doing for us.

We have a fairly large CVS based FAI installation based on a modified
2.8.4.9 fai version. I'm in the process of converting that to 2.10.x
on ubuntu right now. Most annoying change is that 2.10.x will not run
scripts named S[0-9][0-9]*, so you have to rename the scripts to
[0-9][0-9]*, which CVS can't (easily) do. This applies to scripts
defining classes, too.

> Our entire configuration is currently under revision control, and one
> of the things we'd like to do is test our config changes before we
> commit them back to the repository.

We use a STABLE tag for this: you can check new commits by using the
HEAD tag during a test install and then tag the changed files STABLE
if everything went fine. But this is testing after commit, not before.

> Is there currently a way to answering the question "What would FAI
> do?" for a given host *other* than actually FAI'ing that host?

Right. I have been looking for a way to ask FAI this question from the
very first moment we used it. We implemented some sort of dry-run mode
for softupdates. Currently we have some servers that noone dares to run
softupdate on, simply because we can't tell what exactly will happen.

For installs it's much easier: I just take a bunch of vmware-server
instances and install there. It's not exactly the same if your config
depends on specific hardware. But if it does, testing the install on
another machine will be a problem in any case.
 
> I'm thinking of some kind of script which would recurse through the
> config hierarchy and evaluate files and scripts to determine things
> like:
> 
>  - which classes a given host is in
>  - which scripts would run and what the output/results of those
>    scripts would be
>  - which disk config would be used
>  - what files would be installed (via fcopy)
>  - what packages would be installed (and what dependencies would get
>    dragged in)

Great. Let me know, when that script is ready to use ;)

For now I'll keep using vmware-server for testinstalls, works great.
Main problem I see with the script you suggest is that all the scripts
inside the config space would have to be aware of some sort of dry-run
mode. Then you could simulate the install. But I don't think that you
can safely call all these scripts in an environment where different
people independently edit the config space. There might be a script
that formats your disk for some reason...

Regards,

Jens.

-- 
Jens Dreger                      Freie Universitaet Berlin
dreger at physik.fu-berlin.de       Fachbereich Physik - ZEDV
Tel: +49 30 83854774             Arnimallee 14
Fax: +49 30 83855902	         14195 Berlin