Re: Module variables being set late [example]

[Chip Seraphine]

OK, as promised, here is a detailed example.  I think we already nailed down 
what is happening and Mark explained *why* it does this, so feel free to 
ignore.

For what it's worth, I think I can work around the whole thing by breaking my 
imported cf.main file into 3 parts:  Stuff that needs to be done before the 
modules fire (setting some variables and classes in control: and groups:), a 
module-import-only file, and a stuff-to-do-after-the-modules-run file.

Anyway, here's the demo:

3 config files and a module.  The top file (cf.test) imports two others.  The 
first one it imports (cf.test1)  brings in a module that sets the class 
'first'.  However, subsequent actions in cf.test1 do not see this class as 
set.  Subsequent files do, however.

I did not expect for 'first' to be visible in the top file (cf.test) since 
imports happen last.  I did, however, expect it to be defined in all of 
cf.test2 since it happens first in the actionsequence.

The "-I" output is appended below.   I'll send up the -d2 output if anyone 
wants it.

#cf.test
control:
        AddInstallable = ( first second third )
        actionsequence = ( shellcommands )
import:
        cf.test1
        cf.test2
shellcommands:
                "/bin/echo cf.test is running shellcommands"


#cf.test1
control:
        actionsequence = ( "module:setfirst" shellcommands )
        addclasses= ( second )
shellcommands:
        "/bin/echo cf.test1 running shellcommands"
        first:: "/bin/echo first def"
        second:: "/bin/echo second def"
        "/bin/echo defined classes: $(allclasses)"


#cf.test2
control:
        actionsequence = ( shellcommands )
        addclasses = ( third )
shellcommands:
        "/bin/echo cf.test2 running shellcommands"
        third:: "/bin/echo third def"
        first.second.third:: "/bin/echo all def"


#module module:setfirst
#!/bin/sh
echo "+first"


# -I output:
cfengine:cuffs: Executing script /bin/echo cf.test is running 
sh...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo cf.te: cf.test is running shellcommands
cfengine:cuffs: Finished script /bin/echo cf.test is running shellcommands
cfengine:cuffs: Executing script /bin/echo cf.test1 running 
shel...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo cf.te: cf.test1 running shellcommands
cfengine:cuffs: Finished script /bin/echo cf.test1 running shellcommands
cfengine:cuffs: Executing script /bin/echo second 
def...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo secon: second def
cfengine:cuffs: Finished script /bin/echo second def
cfengine:cuffs: Executing script /bin/echo defined classes: 
CFAL...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo defin: defined classes: 
CFALLCLASSES=any:cfengine_2_1_0p1:Friday:Hr09:Min29:Min25_30:Q2:Hr09_Q2:Day9:January:Yr2004:solarisx86:cuffs:32_bit:sunos_5_9:i86pc:sunos_i86pc:sunos_i86pc_5_9:i386:sunos_i86pc_5_9_Generic_112234_08:compiled_on_solaris2_9:net_iface_lo0:net_iface_elxl0:10_10_1_165:10_10_1:ipv4_10_10_1_165:ipv4_10_10_1:ipv4_10_10:ipv4_10:second:third:second:third:
cfengine:cuffs: Finished script /bin/echo defined classes: 
CFALLCLASSES=any:cfengine_2_1_0p1:Friday:Hr09:Min29:Min25_30:Q2:Hr09_Q2:Day9:January:Yr2004:solarisx86:cuffs:32_bit:sunos_5_9:i86pc:sunos_i86pc:sunos_i86pc_5_9:i386:sunos_i86pc_5_9_Generic_112234_08:compiled_on_solaris2_9:net_iface_lo0:net_iface_elxl0:10_10_1_165:10_10_1:ipv4_10_10_1_165:ipv4_10_10_1:ipv4_10_10:ipv4_10:second:third:second:third:
cfengine:cuffs: Executing script /bin/echo cf.test2 running 
shel...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo cf.te: cf.test2 running shellcommands
cfengine:cuffs: Finished script /bin/echo cf.test2 running shellcommands
cfengine:cuffs: Executing script /bin/echo third 
def...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo third: third def
cfengine:cuffs: Finished script /bin/echo third def
cfengine:cuffs: Executing script /bin/echo first 
def...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo first: first def
cfengine:cuffs: Finished script /bin/echo first def
cfengine:cuffs: Executing script /bin/echo all def...(timeout=0,uid=-1,gid=-1)
cfengine:cuffs:/bin/echo all d: all def
cfengine:cuffs: Finished script /bin/echo all def

The point of interest is that the "echo first def" line never fired.  
Subsquent imports worked fine, however. 


On Thursday 08 January 2004 15:14, you wrote:
> From the code:
>
>    if (pass == 1)
>       {
>       CheckForModule(actiontxt,args);
>       }
>
>
> With this test program:
>
>
> control:
>
>    actionsequence = ( disable module:test alerts )
>
>
> I see:
>
> *********************************************************************
>  Main Tree Sched: disable pass 1 @ Thu Jan  8 22:12:38 2004
> *********************************************************************
>
> Filetype all, /tmp/bla is not there - ok
>
> *********************************************************************
>  Main Tree Sched: module:test pass 1 @ Thu Jan  8 22:12:39 2004
> *********************************************************************
>
> ---------------------------------------------------------------------
> (Plug-in /var/cfengine/modules/module:test not found)
> ---------------------------------------------------------------------
>
>
> *********************************************************************
>  Main Tree Sched: alerts pass 1 @ Thu Jan  8 22:12:39 2004
> *********************************
>
> This shows that things happen in the correct order. So I am guessing that
> the problem is something else.
>
> Mark
>
> On  7 Jan, Chip Seraphine wrote:
> > 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
> > :-)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
> Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~