[Beowulf] DCC (debian cluster components)

[Robert G. Brown]

On Sat, 5 Mar 2005, Guy Coates wrote:

> > In the "modern" era of PXE, on "most networks" adding new machines
> > with specific configurations could be done with a single command or GUI.
> > We're not there yet. :-)
> 
> The only thing that ever came close was RLX's Control Tower management
> software. It did "one click" management and provisioning of machines.
> One the blade systems it could even do "zero click configuration", as you
> could set policy like
> 
> "Any machines I put into slots 1-10 should automatically get configuration
> Y put on them."
> 
> It was generic enough so that it  could provision any operating system you
> could think off, and if it didn't do something you wanted it to, it was
> also easy to dig under the covers and hack the code.
> 
> The only down side was the price-tag, which was extortionate.
> 
> Guy
> 
> 

I agree that there is some work involved in building a PXE installable
configuration for e.g. kickstart, but it isn't excessive.  Take template
kickstart file(s).  Edit it to select package set(s) for same(different)
node config(s). Put it(them) on server.  Edit dhcpd.conf to to point to
bootloader in /tftpboot.  Edit boot.msg, pxelinux.cfg/default to point
to (list of) node type(s) and point to the associated kickstart file(s)
and boot option(s), respectively.  Boot.

There IS a GUI for building the kickstart file (under RH and FC, at
least), although I suspect that most people would use this at most to
build the template and then tune it up by hand -- it is actually easier
to edit a flatfile with an editor once you see the layout.

dhcpd doesn't have a GUI to front it AFAIK, so this remains a place one
could do some work.  It would be useful to build one that tests the
URL paths to e.g. the kickstart files and the tftpboot paths to the
initrd images.  It would be even lovelier to have the same interface
edit boot.msg and pxelinux.cfg/default at the same time so that all
three could be consistent.  This is the one place I find myself hopping
from directory to directory to make matching changes, as I create an
image for "fc3 workstation" or "fc3 node" for testing purposes and need
to ensure that the matching kickstart file is in the right place and
correctly corresponds to the dhcpd entry.  This is even more true if one
wants to create an image indexed per IP number (the "right" way,
arguably, for tftpboot to function) so that everything becomes totally
automagic.

I always am of two minds about high-level front ends to low level admin
commands.  Yes, they are convenient and let newbies start to work with a
low buy-in as far as learning curve is concerned.  However, they also
SHIELD a newbie from learning what they really need to know to be an
effective manager, and (to my own experience anyway) they rarely work
stably as the various tools upon which they are built evolve.  For one
thing, the GUI designer almost always omits features and capabilities of
the lower level stuff, so eventually you want to do something you "know"
can be done but the GUI doesn't.  For another, somebody changes
something really subtle, such as a default pathway in /tftpboot, and
your GUI "breaks" and you have no idea why and won't until you learn,
in a panic, all the things the GUI shielded you from.

I tend to think GUIs work best when they are a standard part of a single
administrative package co-developed by the packages maintainers.  A GUI
that spans multiple tools and functions simply has more issues.  Hence
redhat-config-kickstart has a chance to remain useful, but building its
functionality into a sweeping redhat-config-pxe (including kickstart,
dchpd, tftp) is a bit dicier.

STILL POSSIBLE, mind you -- it just needs somebody to love it and
maintain it.  That's why I asked about FAI -- if somebody doesn't
actively maintain the GUIs, the scripts, the documentation, as the
underlying toolset slowly changes, eventually the friendly front end
fails to encompass all sorts of desireable functionality or starts to
break, sometimes, for some users, trying to do some things.  In FC or
RH, there is no "supertool", but the individual tools work well and
aren't THAT hard to learn -- most of them have dedicated HOWTOs.  Some
supertools exist in ROCKS and warewulf and so on, and have (at the
moment) devoted maintainers who love their product.

    rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu