help-cfengine
[Top][All Lists]
Advanced

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

Re: list iteration?


From: Luke A. Kanies
Subject: Re: list iteration?
Date: Wed, 5 May 2004 17:59:40 -0500 (CDT)

On Wed, 5 May 2004, Tod Oace wrote:

> On May 5, 2004, at 07:38, Luke A. Kanies wrote:
>
> > There are no restrictions on the number of control sections you have.
>
> And it's effectively the same as putting them all in one place anyway,
> right? Cfengine coalesces everything into memory figuring out which
> things depend on which other things and then processes it all in the
> way it best sees fit. Or at least that's how it seemed after one
> cfengine debugging session anyway.

That is the case for most actions, but not for control (or any other meta
action, like classes and import).  Cfengine does not clearly delineate
what happens at run time vs. parse time; setting variables is basically
done at parse time (before any actions are executed).  The following code:

control:
  variable = ( fun )

classes:
  test = ( any )

control:
  yay = ( fun )

results in 'variable', then 'test', and then 'yay' being set.  So no, in
this case they do not all get aggregated, because nearly everything that
gets done in the control action gets done at parse-time, whereas all of
the functional actions get aggregated at parse time, and then executed at
run time.

I hope to provide some good documentation of this process at some point,
because it is certainly one of the things I wanted to know when I first
started learning cfengine, and it can really help push the boundaries.

> This functionality wasn't obvious to me at first, but I really like it.
> It means I can have a cf.sendmail that ensures smmsp is in /etc/group
> and also have a cf.apache that ensures www is in /etc/group. The two
> files don't have any dependancies on each other. I organize the work in
> a human way and cfengine coalesces it into an optimized computer way.
> Right?

Basically, actions which do work (which I call functional actions) all get
aggregated.  Actions which modify how cfengine operates (which I call meta
actions, and are largely 'control', 'classes/groups', 'import', and maybe
'ignore' and 'filters') all get interpreted at parse time and thus do not
aggregate.

Note also, of course, that this aggregation means that you cannot
independently control in which order assertions happen.  If the first file
you import pulls down a config and then sets a class to restart a
process using shellcommands, but the second file edits a file and sets a
class to copy another file down, e.g.:

# file1
copy:
  /path/to/file dest=/new/path/to/file define=restart

shellcommands:
  restart:: "/path/to/restart command"

# file2
editfiles:
  { /file/to/edit
    AppendIfNoSuchLine "this is a line"
    Define "makecopy"
  }

copy:
  makecopy::
    /path/to/other/file dest=/new/path

-----------------------------

If you do this, then you basically get copy, copy, shellcommands,
editfiles.  This is why cfengine has two passes; the 'makecopy' would be
done on the second pass.

Um, yeah, I think that about covers it.

Luke

-- 
Like frozen sentries of the serengeti, the century-old termite mounds
had withstood all tests of time and foe - all tests, that is, except
the one involving drunken aardvarks and a stolen wrecking ball."
                -- Gary Larson
---------------------------------------------------------------------
Luke Kanies | http://abstractive.org | http://reductiveconsulting.com




reply via email to

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