[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
imports.
> 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
312-264-2048
chip@trdlnk.com
FTP