MLH writes:

> > Why do you need to move?  Solaris/x86 is a good platform, and
> > Solaris 10 is even better.  Do you have some application- or
> > cluster-specific reason for moving away from Solaris?
>
> Currently we are a 'solaris shop' and while solaris86 currently
> does smp better than anything else we've seen for these boxes, it
> isn't a long term solution and has some painful software maintenance
> challenges

Hmmm... I don't really know what you mean here, except that of course
there is a difference in patch distribution etc., since Solaris is
proprietary and tied to a single vendor.

> (and is very slow).

Slow is relative.  My guess is you mean good SMP performance but
slow I/O (especially when compared to Solaris/sparc-based systems).
Some of this is architecture-inherent.  Also, there are many tunables
in Solaris, and tweaking them all takes some time.  I do not think
Solaris is slow per se.

> We see Sun moving further and further
> away from the scientific community that helped give it life and
> that continued movement makes it harder and harder to maintain and
> develop our software tools.  We are a data-centric research
> organization with very long-term goals and requirements. Being held
> hostage by a technology or vendor does not fit in with these
> constraints.

So you feel compelled to move to an open-source platform because
you see this as the only way to protect your prior investment in
software development and data collection?  Another topic that
surely warrants discussion, but no longer relevant for a cluster-
oriented list...

> > > At the same time, we would like to work on some sort of cluster
> > > install/management package.
> >
> > This sounds like a good thing to have.  But the first step would be
> > to implement a method for doing fully automated "hands-off" NetBSD
> > installations.  This is something that has been sorely lacking since
> > NetBSD came into existence...
>
> Suggestions? :^)

Sure, I have some, but:

  - The problem is old and has been discussed before.

  - This is not the appropriate list.

  - NetBSD has a tradition of "putting the money where the mouth is"
    and showing some code before entering a discussion, and I haven't
    really found the time to sit down and hack away...


Anyhow, here's what needs to be done:

  - Implement system packages in such a way that a "make" in any of
    the source directories would result in a system package definition.
    This definition could then be used to create a package and/or
    define a software bundle as a building block of an installation
    unit ("set" in NetBSD-speak).

  - Define a system definition data format.  This could be an XML
    file describing all aspects of a system to be installed (fs
    layout, network config, software bundles to be installed, etc).
    [Don't make the mistake Sun made by fanning out into several
    config files for different information needed by their Jumpstart
    installation process.]

  - Implement various "do-it" programs that parse the XML file,
    pick out their task (the sys_disk tool creates the slices, the
    sys_fs tool creates the file systems, the sys_net tool writes
    the network config info, etc).  There is a moving boundary here
    since a lot of the configuration could also be done in package
    scripts.

Given such an infrastructure, you would only have to fill out the
XML file, place it on the install server (or in your LDAP repository
or HTTP server or whatever), perform a network boot and lazily watch
the system install itself.  :-)

This scheme could easily be extended to incorporate disk mirroring,
cluster configuration, etc.  Additionally, you could define a branch
point where a system image is unpacked on the installation target
instead of adding individual software bundles.  This system image
would have to be pulled from a "golden" cluster node beforehand.
Since that "golden" node was set up via an XML file itself, you could
even pull in a "baseline" system image (to save time) and then
add individual software bundles depending on the individual install
target configuration.

None of this is new or original, several vendors have implemented one
or more parts of this for their platforms.  When I find some time for
hacking on NetBSD, this is certainly a topic I will work on... whenever
that may be. (Unless of course I get paid, in which case I can start
right away :-)))


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW: http://www.bb-c.de/~vab/
Meckenheim, Germany                                   Email: vab@bb-c.de