Class concept for the FAI config space

[Robert Markula]

Hello all,

I'm successfully using FAI for 10+ years now. It's a great tool and
forms, along with Cfengine, the base of my whole server and client
deployment.

However, in retrospect, over the years I found myself always struggling
to keep the config space up-to-date, especially on updates of the config
space or FAI itself. So after an update, in order to keep everything as
it should, I'm diff'ing the old config space - with my own
customizations - to the new vanilla one, migrating over my custom
changes to the new config space (or vice versa, whatever makes more
sense). This process is cumbersome and error prone.

Also, the config space itself is not as vanilla as I'd personally like.
E.g. I don't necessarily want my motd to be changed. Of course, this is
easy to fix, but it makes the custom changes to the config space even
more cluttered.

Thinking about how to mitigate problem I realized that one of FAI's
strengths is its 'class' concept. Now, wouldn't it make sense to extend
the class concept to the config space as a whole?

Imagine you could use multiple config spaces at once. Imagine the
following config spaces:

- BASE/ (just the very basics that are needed for FAI to work)
- BASE_DEBIAN/ (just the very basics that are needed to install a
working Debian host)
- BASE_UBUNTU/ (just the very basics that are needed to install a
working Ubuntu host)
- BASE_CENTOS/ (just the very basics that are needed to install a
working CentOS host)
- BASE_SUSE/ (just the very basics that are needed to install a working
SUSE host)
- DEMO/ (things like motd changes, etc.)
- CUSTOM_*/ (site-specific customiziations)

The idea is that all BASE_* config spaces just include what is
absolutely necessary to install a host. You could use them from the FAI
repo unmodified as they come. Consequently, they should be as minimal
and as vanilla as possible.

A host that is assigned the 'BASE', 'BASE_UBUNTU' and 'CUSTOM_XYZ'
classes would then use all the merged configs in these separate config
spaces.

So a FAI admin would just have to maintain the site-specific 'CUSTOM_*'
config spaces and could use all 'BASE_*' config spaces unchanged as they
are, updating them with new versions from the repos as time goes by.
IMO this would provide a clean update path and provide for nice versioning.

It would even simplify contributions to the FAI config space:
Want to enable support for next-gen filesystems in FAI? 'BASE_BTRFS' or
'BASE_ZFS' could do it. Need to support a new desktop environment?
'BASE_XFCE' and you're good to go. Encryption? 'BASE_NBDE' to add
support for modern Clevis and Tang. Initramfs-tools would go to the
BASE_UBUNTU, dracut to the BASE_DEBIAN one... or use a generic
BASE_INITRAMFSTOOLS and BASE_DRACUT config space anyway.

Basically everything that requires a complex configuration (e.g. a
mixture of debconf/, disk_config/, files/, hooks/, package_config/ and
scripts/) could go to its own config space, in the style of the good old
UNIX philosophy of 'do only one thing and do it well'. Cleanly
seperated, easy to maintain and contribute to.

What do you think about that? Would something like this be even feasible?


Robert