On Mon, Jun 30, 2003 at 02:04:29PM -0500, Luke A. Kanies wrote:
> What I've been thinking about (but have not fully put into practice) is
> trying to lose the host type model entirely, but instead just collect
> ordered lists of related work, and attach those to various hosts. If
> you're a solaris box, then run these five lists, if you're a web server,
> run this one, if you're an apache server, run this list; if you're all of
> those things, then run them all.
Ah hah. This is what I was trying to say (badly) when you and I were
talking about the pros and cons of "host classes" when I was in
Nashville. You were talking about something that wound up being (in
part) the v3 'types' model. I was at the same time fumbling through an
attempt at trying to describe my own (bad) experiences with trying to
use host classes -- they fall apart over the long run. Every time, I've
always would up back with just simple ordered lists of things (the
prereq lists in makefile stanzas) which get concatenated together in
different combinations (defined in the v2 hosts.conf file) to make
different machines.
(Background for people who haven't played with both: The 'types' model
is something that showed up in isconf v3, as part of a more detailed
host classing mechanism which I should really leave to Luke to explain;
the v2 configuration files instead consist only of one or more
makefiles, and a hosts.conf file which basically just sets up
environment variables before running 'make'.)
The "work lists" you're describing above are the way I've always thought
of this, without using those words. I guess the main difference between
host classes and work lists is that host classes are usually implemented
as some abstract, maybe even inheritable thing with attributes that can
be twiddled as if the class were a black box, while work lists are just
dumb ordered lists of commands to be run, usually without much in the
way of conditionals, where the sysadmin has to understand the line-item
detail in order to make much use of them at all.
I still don't think that's a very good clarification of the difference
between the two. A better description would probably include a
discussion of the independent variables: In work lists, the independent
variable is time; they're pretty much blind to everything else. In
classing, the independent variable is something else, I'm not sure what.
Every time I've tried to make more complicated tools I've wound up right
back with this same dirt-simple model -- work lists. The turing paper
claims that these work lists have to be fully ordered in order to be
100% reliable. In practice, we all know that the best they'll ever be
is partially ordered, overlapping, and so on.
You said that work lists shouldn't overlap -- I betcha they always will.
I think what you did with the timestamps in v3 was a stroke of
appropriate genius in solving that problem, and something like it is
probably always going to be a feature of any tool that attempts to make
reproducible changes.
Steve
--
Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna Aerospace LLC
[email protected]
http://www.stevegt.com -- http://Infrastructures.Org
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.