Re: [Condor-users] Resending: Condor Configuration Management RFC

[David McBride <dwm@xxxxxxxxxxxx>]

On Mon, 2005-09-12 at 15:54 -0700, Michael Yoder wrote:

> We'd like to ask you, the
> Condor Community, to comment on our design and suggest new features.  

Hi,

I've reviewed the proposal.  At it's heart, it appears to suggest the
introduction of the following features:

- Using a RDBMS to store live configuration data.  
- Exporting the RDBMS contents from a new Configuration server.
- Graphical and commandline tools for updating the configuration server.
- Arrange the configuration data to allow hierarchical configurations,
eg:
	Common:		Site -> Pool -> Host
	Unix-specific:	Site -> Pool -> Host
	...

These are interesting ideas.  I would make the following comments:

- Using a RDBMS is (probably) overkill unless you've got a really huge
set of hosts.  Database systems really come into their own when you need
to be able to make a (large) number of changes to a datastore whilst
maintaining transactional consistency.  Certainly in the 400-500 node
pool that I maintain, updating flat files and running `condor_reconfig
-all` is sufficient.

- The introduction of a RDBMS introduces a new question: change
management.  With flat files, existing revision control systems -- RCS,
CVS, SVN, Arch, or whatever is locally appropriate -- can be used to
record changes and manage rollbacks of configurations as required.
Whilst a RDBMS can certainly *provide* atomic snapshots at moments in
time, this functionality is usually not automatic and some additional
facilities would be needed to implement good revision control.

- A graphical utility to aid someone unfamiliar with Condor with system
configuration could be useful to those who are unfamiliar with Condor.
Typically, I find the comments in the standard template configuration
file (and where I'm confused, the manual) to be sufficient.

- The hierarchical configuration concept is a vital one for even
moderate-sized pools.  I already use a slightly less general
hierarchical system than the one you describe using the existing Condor
facilities:

* I keep one global configuration file for each pool located on a
centrally-provided network filesystem. A symlink
from /etc/condor/condor_config on each participating machine points to
this global file.

* This file contains all of the default configuration directives for
every daemon in the entire pool.  (My current live file is currently
publically visible at http://www.doc.ic.ac.uk/condor/doc-config/).

* This file includes, using the LOCAL_CONFIG_FILE directive, two files
(if they exist): .../$(HOSTNAME)/condor_config.local
and .../$(ARCH).$(OPSYS)/condor_config.arch.  These files contain host
and OS-specific configuration entries, respectively, that can be used to
override any of the pool-wide defalts.
	
* In my specific case, I typically have several different classes of
machine -- master node, submit-only, batch, desktop, etc.   Symlinks are
used to group particular host configurations.

With this configuration, I can quickly and easily make pool-wide,
architecture-specific, class specific or host-specific changes to my
Condor pool.


To conclude, my preference would be to keep the existing Condor
flat-files mechanisms for the live pool configuration.  

If I had a very large number of nodes to manage, I would store a
hierarchy of configuration options in some form of template or database,
and then using glue scripts to *generate* from that the Condor
configuration files.  

But this is a "push" mechanism rather than a "pull", which in practive
has been more reliable in other systems where we have adopted this
approach.  For example, our live DNS, DHCP, SMTP and other service
configurations are all generated from databases in this manner.

Hope this helps.

Cheers,
David
-- 
David McBride <dwm@xxxxxxxxxxxx>
Department of Computing, Imperial College, London

Attachment: signature.asc
Description: This is a digitally signed message part