Class conflicts (was: grub and grub_pc)

[Stephan Adig]

Hi Thomas,

On Wed, 2011-01-26 at 12:56 +0100, Thomas Neumann wrote:
> hiya
> 
> >> Hello, may a client belong simultaneously to GRUB and GRUB_PC classes?
> >> If not, if a client belongs to GRUB_PC class,
> >> the /files/boot/grub/menu.lst/GRUB
> >> will not be copied to the new system installed.
> 
> > Nope...GRUB and GRUB_PC are seperate bootloaders.
> 
> > A server or install client should only belong to one class.
> 
> How to tell that someone is doing something stupid? From the software's
> point of view, a class combination of "WEBSERVER DBSERVER DHCPSERVER" is
> as valid as "DEBIAN UBUNTU X86_32 X86_64".
> 
> Is it useful to have some kind of list(s), where one could specify classes
> that do not play well together? "pick on of these"

Right. But I think that is something someone should do also when you
setup your FAI framework.
At our place, I do have class priorities inside the classnames.
e.g. 
10_ARCH_AMD64
10_ARCH_i386
20_DISK_LAYOUT_HP_BL465_G5
20_DISK_LAYOUT_HP_BL465_G7
30_ENV_PRODUCTION
30_ENV_INTEGRATION
50_OS_UBUNTU_10_04
50_OS_UBUNTU_09_10

60_APPLICATION_SPECIFIC_CLASSES

So the admin who setups the layout for the machine should know what to
do..

On my todo for the dc2 frontend / backend, I want to provide a mechanism
to provide errors for classes which are not meant to be used together.

I don't know if Thomas or others have that on their radar.

Regards,

\sh
-- 
Stephan '\sh' Adig
SysAdmin / Ubuntu Developer
xmpp: sh at sourcecode.de