[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PrepModules() rocketh mightily

From: Chip Seraphine
Subject: Re: PrepModules() rocketh mightily
Date: Mon, 17 May 2004 13:44:31 -0500
User-agent: KMail/1.5.4

On Monday 17 May 2004 13:21, John Sechrest wrote:
> I would love to understand how you used PrepModules.
> Do you have an example of a module you wrote?

Not one that I am ready to share.  The module in question that was most 
affected runs a bunch of tests to make discoveries about the local 
environment (such as determining what sort of application server it is based 
on parsing locally-available database output and files).  Since almost 
everything cfengine does hinges on the role that the system plays, I need to 
find that out early.

> Can you explain how it simpified things?

Running the module out of groups: instead of the actionsequence allows me to 
access the classes in the control:  section without having to due gratuitous 

> Can you outline what things this makes better for you?

Cleanliness, really.  I have a top level cfagent.conf that I basically want to 
use just for setting up some groups, defining the Installable classes, and 
importing all the other files.  In the past, I had to run my diagnostic 
modules in this file even though they didn't logically belong there, because 
otherwise my imported files might not be able to see the results of the 
modules (.e.g access classes installed by those modules). 

Now, I run the modules in my imported cf.main file (where all the other 
diagnostics are done).  This is not only cleaner, but since I can control 
what classes of machines import cf.main, I don't have to run the diagnostics 
machine everywhere in the top level file.  (This could be done before, but 
only by maintaining lots of different actionsequences-- ugly.)  This is nice 
as (for instance) I do not need to have my Solaris boxes worry about 
application diagnostics that I know can only be found on Linux boxes.

> Does it allow you to abstract your code enough that you can
> write a module/ruleset for a role which you could share with someone
> else and they could put it into service without changes?

I don't think it really impacts *that*.  What you describe is just writing 
tidy code with good abstraction and decent documentation and comments.  (I 
write most modules in Perl, so I can embed POD in them.  This lets me keep a 
nice stable of module man pages by running pod2man on them.)  And, of course, 
having a module that is appropriate for general use and not just handy for 
some local purpose.

I have a 'rotation' module that I use for dispersing high-load jobs 
chronologically and physically.  I could tidy up those docs and post it; 
others might find it handy.

Hey Mark-- now that we are gong the CVS repository route, can we have a 
modules area for this sort of thing?  We'd need an upload/contrib area on an 
anon ftp server somewhere, so that those with commit access could review and 
post 'em....


Chip Seraphine
Unix Administrator
TradeLink, LLC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]