Re: Module variables being set late

[Chip Seraphine]

On Wednesday 07 January 2004 14:00, you wrote:
> On  7 Jan, Chip Seraphine wrote:
> > I am running a module at the top of my actionsequence, and it sets a
> > class ("foo").  Foo *is* an AddInstallable class.
> >
> > Unfortunately, the module runs only *after* everything else in the
> > actionsequence, even though it is the first item on the list.  (I'm not
> > sure, but I believe that this is new behavior in 2.1; the problems this
> > behavior is causing did not exist prior to that.)  This is causing the
> > "foo" class to not be set until too late to do any good.
> >
> > I've tried running the module the old-style way (with
> > "module:modname.foo"), but that did not cause it run a the desired time.
> >
> > Any ideas?  Any way I can for the modules to run at the beginning of the
> > first passs, which what I really need it to do?
>
> This is factually incorrect. The modules are run in the correct place
> in the actionsequence. Whether or not the variables are "received" by
> the actions is a different issue.

I'm fairly certain they are running late.  The modules also generate syslog 
messages, and those appeared in syslogs only after logger calls from  "later" 
in the cfengine script.

> You need to tell us exactly what
> you are doing.

I have a top level file that sets some very basic parameters and then imports 
a couple of settings-type files (cf.network, which contains or discovers my 
network and DNS information and cf.groups, which is my "control panel" that I 
use to regulate who does what) and then starts importing other cf files.  The 
first of these is 'cf.main', which does all the nuts and bolts including 
running most of the modules.  (The modules are the very first items in 
cf.main's actionsequence).  Subsequent files are task-oriented (e.g. 
cf.crontabs maintains a bunch of cron entries and backs up some cron-related 
stuff) and just do things that are a little too bulky to throw in cf.main 
without it becoming spaghetti.

Anyway, one of the modules cf.main runs determines wether or not some in-house 
apps are supposed to be running on the current host by querying some local 
files and databases.  (The authority point for this stuff was established 
long before the cfengine rollout, so in this case some app file content tell 
Cfengine what to do instead of Cfengine dictating the file contents).  I set 
flags from this, which then tells cfengine to do various health-related tasks 
in a manner appriate for that machine based on the flags  (process lists, 
disk space thresholds, user passwords, the big ugly 'PRODUCTION MACHINE' 
banner, etc).

The problem is that this scheme results in the modules imported by cf.main 
running after the tasks that need their results.

I can get it to work by running my modules at the top level (cfagent.conf), 
but this seriously uglifies my "control panel", as it means I have to assign 
all groups that affect the modules in cfagent.conf itself so that the modules 
can see them.  This is a problem because my cf.groups file makes use of 
variables and classes set in preceding files; a lot of it  cannot be easily 
done in the 'top' file without some shellcommands: or control: section 
running before it (which is the whole reason that cf.groups is a seperate 
file in the first place).  For example, some 'control classes' that regulate 
behavior are turned on/off by results from my cf.network file.

Well, that's as specific I can get without pasting in bug hunks of config :-)