On Jan 19, 2007, at 8:55 AM, Paul Anderson wrote:
I'm sure that I seen several comparatively simple examples in a
similar vein (Ed?). I worry about how you get from there to
something practical.
I feel similarly.
I completely agree that solutions to this problem should essentially
be orthogonal to the problem of actually making the changes (I tend
to think it's a layered relationship, but it doesn't really matter).
The big problem I see is what the interface between the two sets of
solutions is.
For instance, I've been thinking of change control (which is
basically what this is) as a layer above configuration management,
and then trying to figure out what information needs to pass between
the layers. At the least, they need to agree on what services could
be running and who could run them (and they should probably support
different levels of "can run", from "i could install everything and
then run" to "all I need to do is run the startup script)).
I expect it would be the responsibility of the change control layer
to maintain the list of what services should run on which nodes, so
that the configuration management layer is only responsible for how
to manage a given service.
Puppet is already somewhat prepared for this, because the node/class
mappings can be pretty easily moved out of it into an external
database or something, and then Puppet would just query this
information when configuring a node. However, there's no way
currently to ask Puppet which nodes are correctly running a current
service.
So, as Narayan mentioned, the feedback mechanisms because pretty
important and painfully complicated. Just having configured a
service isn't sufficient -- the change control layer needs to know
whether the service (whether it's a TV tuner or a database service)
is running. The only way I can see to do this is to have good
feedback systems, which is why I've been planning on making Runnels
[1] for more than a year.
How do you specify what you want in a simple and concise way -
having someone (sysadmin?) write arbitrary code in a logic
programming language and let it lose to reconfigure my network
would make me a little twitchy :-) - you still want to allow the
flexibility though - perhaps you need to provide some layer which
restricts what is possible, and makes the application context
clearer - for example "remove server A while maintaining these
properties ....."
At this point, we should focus on defining the interaction with this
layer and worry about competing tools later. I'd be highly surprised
if low-level people would ever interact with this layer, and someone
has to make this kind of decision; you might as well give them
powerful tools to do so.
It is also hard to specify all the correct constraints in practice
- my previous example being migrating some service on to somebody's
laptop because there wasn't any constraint to say that this was a
bad idea ....
Yeah, constraints become pretty important when making this kind of
decision. Following my layers, the config mgmt layer would need a
standard way of talking about constraints, and the change control
layer would need that information in order to make its decisions.
It seems somewhat reasonable (this is somewhat off the cuff) to think
of constraints as simple booleans like the classing/grouping
mechanisms, such that membership or lack thereof in a group would be
considered a constraint. So, you could constrain your services to !
laptop or to any other class of machine based on location or platform
or whatever.
But I really would like to see this approach followed up a little
further.
I have zero time right now, but I might be able to initiate a
student project to play with it and keep me involved .... (?)
This is something I've been mentally modelling for a while. The
latest release of Puppet supports allowing external programs to
specify node/class relationships (a very simple output format is
required -- the parent node on the first line, whitespace-separated
classes on the second), because I could tell that people wanted to
make this kind of decision in a tool very different from Puppet.
There are also multiple kinds of mappings. At the least, there are
manual and automatic mappings -- classes like hardware, platform,
and ip space classes should be automatic (and, of course, location
*should* be automatic but basically never is), but classes that
determine which service should run where will always look basically
manual (even if it's a computer doing the manual setting).
Puppet currently does the automatic mappings using variables, so
you'd do something like this:
include $operatingsystem
to set the appropriate automatic class on a system. This should be
more like data, in my opinion, but it requires information from the
host, which I'm hesitant to push up to the change control layer.
So, I'm thinking that the configuration management layer should have
an automatic class mapping module, such that the interface between
the two layers would have the config mgmt layer determining automatic
class memberships (which would include things like whether a machine
is a laptop, based on hardware type) and passing that to the change
control layer to determine the rest of the class memberships.
I'd love to write Puppet to someone else's change control layer. If
anyone (Andrew?) is interested in working on this, I'll do whatever I
can -- including getting new releases out with this ability -- to
work on it, because I know (based on customer feedback) that this is
the next big hurdle.
I also have been thinking about using these booleans to handle
versioning interfaces. E.g., every class would be mapped to a
version control system, such that you could ask for a class and a
version (or, more likely, a stability level), and Puppet would know
how to retrieve the associated code from the version store. This
puts even more power into the hands of these booleans, but I think
they work pretty well.
--
The easiest way for your children to learn about money is for you
not to have any. -- Katharine Whitehorn
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
