PrepModules() rocketh mightily
Chip Seraphine
I just wanted to give kudos to the new(ish) PrepModules feature. I finally
got around to implementing it, and it allowed me to considerably
de-spaghettify some of my scripts. Thanks!
Any of you out there who have extra layers of importing in order to get your
module classes set at the right time really ought to take a look at this.
It's good stuff.
--
Chip Seraphine
Unix Administrator
TradeLink, LLC
312-264-2048
ch...@trdlnk.com
John Sechrest
Chip Seraphine <ch...@trdlnk.com> writes:
% 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 keepa
% nice stable of module man pages by running pod2man on them.) And,ofcourse,
% 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.
Yes, I think that the more well written , highly abstracted tools
that we can share on the list, the better.
I would love to see your rotation module.
% 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 anupload/contrib area on an
% anon ftp server somewhere, so that those with commit accesscould review and
% post 'em....
That seems like a great plan.
I am currently frustrated with Savannah Support and the associated staff.
I will have to look at gforge and see if we can set something up there.
-----
John Sechrest . Helping people use
. computers and the Internet
. more effectively
.
. Internet: sech...@peak.org
.
. http://www.peak.org/~sechrest
John Sechrest
I would love to understand how you used PrepModules.
Do you have an example of a module you wrote?
Can you explain how it simpified things?
Can you outline what things this makes better for you?
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?
Chip Seraphine <ch...@trdlnk.com> writes:
%
% I just wanted to give kudos to the new(ish) PrepModules feature. I finally
% got around to implementing it, and it allowed me to considerably
% de-spaghettify some of my scripts. Thanks!
%
% Any of you out there who have extra layers of importing in order to get your
% module classes set at the right time really ought to take a look at this.
% It's good stuff.
%
% --
%
% Chip Seraphine
% Unix Administrator
% TradeLink, LLC
% 312-264-2048
% ch...@trdlnk.com
%
%
%
% _______________________________________________
% Help-cfengine mailing list
% Help-c...@gnu.org
% http://mail.gnu.org/mailman/listinfo/help-cfengine
Chip Seraphine
>
> 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
ch...@trdlnk.com
FTP