[Top][All Lists]

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

Re: Imports act weird...any good workarounds?

From: David Kewley
Subject: Re: Imports act weird...any good workarounds?
Date: Thu, 29 Apr 2004 16:11:59 -0700
User-agent: KMail/1.5

Paul Krizak wrote on Thursday 29 April 2004 11:38:
> I'm working on deploying cfengine for our cluster of around 2800 hosts.
> One of the problems I've run in to is that the "import:" directive
> doesn't function as expected.  According to the documentation, imports
> are processed *after* the main script runs (as oppsed to before, like
> pretty much all other languages).  I've got a file, cf.classes, that
> contains information about the global classes (and some global
> variables) that I'd like to be able to use in other cf.* files.  When I
> use the import: directive in one of these files, for example:
> import:
>   any::
>     cf.classes
> editfiles:
>   tx::
>      do some TX stuff
>   ca::
>      do some CA stuff
> the "tx" and "ca" classes are defined in the cf.classes file, but have
> no effect in this file.  Is there any way to force cfagent to apply the
> settings in import: directives *before* it runs the rest of the script?
> The only workaround I can think of is "running" cf.classes, and defining
> some environment variable so that cf.classes sets up the global stuff,
> then *it* imports the cf.* file that I want to run.  This solution is
> kludgy, though; I'd rather have the cf.* files be more script-ish and
> use the import: directive as expected.

Here's how I've got my stuff structured.  First of all, there is a 2-level 
directory tree.  The top directory has the following files a and 
  <a bunch of module subdirectories>

Each module subdirectory has: --> ../
  cf.import --> cf.<module>.imports

and possibly other files and/or subdirs.

cf.<module>.imports has:



The top level cf.imports imports all the cf.imports from all the module 
subdirectories. is made executable, and its first line is

  #!/usr/sbin/cfagent -f

The rest of looks like this:


        <macro defs>

        <cfagent control parameters>

        actionsequence = ( ... )


        ${PWD}/cf.imports     <-- this is the key to much of the modularity

If I run ./ in the top-level directories, all modules are run.  If 
I run it in any subdir, only that module is run.  This scheme also allows you 
to make a  pseudo-module subdir that only contains a symlink to, 
and a cf.imports with a listing of cf.imports from a subset of the available 
modules.  When you run ./ in that pseudo-module subdir, you run 
only the modules that are listed in the cf.imports.  This is handy e.g. if 
you want to different module subsets at different time intervals.

This may likely not work for you, Paul, and may not appeal to anyone else 
either, but I think it's a really, really cool and useful system.

As a last note: I've boiled this description of my system down to the relevant 
details.  There are other bits of interesting funcionality that I haven't 
described here.  If I were to describe that other functionality, you'd see 
that the above description is an approximation -- it's not precisely what I 


reply via email to

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