help-cfengine
[Top][All Lists]
Advanced

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

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


From: Paul Krizak
Subject: Re: Imports act weird...any good workarounds?
Date: Thu, 29 Apr 2004 15:36:57 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

That was how we originally were doing it, but due to reasons beyond the scope of this thread, we moved to individual cf.* files.

Paul Krizak                         5900 E. Ben White Blvd. MS 625
Advanced Micro Devices              Austin, Tx  78741
MPD Linux Systems Co-Op             Phone: (512) 602-5860
Paul.Krizak@amd.com                 Cell:  (512) 791-0686



Chris Edillon wrote:

On Thu, 29 Apr 2004, Paul Krizak wrote:

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.

 i posted something quite a while ago regarding a similar topic.
basically, when you define a class it can be seen by all of the
actions defined in other imported cf.* files of the same "tier",
but not in a parent (like environment variables defined in a
subshell aren't seen by the parent shell process).  so, if you
have a cfagent.conf which does this:

import:
 any::
   cf.classes
   cf.do_cool_stuff

 linux::
   cf.do_linux_things

any classes defined in cf.classes will be valid for any actions
defined in cf.do_cool_stuff and cf.do_linux_things, but not for
any actions defined in your cfagent.conf file itself.  given
that, instead of trying to import your cf.classes file within
each of your other cf.* files, you could import all of your
cf.* files (including cf.classes) in cfagent.conf.  that is,
your cfagent.conf file would simply be a place for your
command: section and an import: secion, and all of the real
work would get done in your cf.* files.  maybe that would be
helpful for your situation.

chris







reply via email to

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