Re: problem with copy stanza not firing

[Luke A. Kanies]

On Thu, 4 Dec 2003, Eric Sorenson wrote:

> On Thu, 4 Dec 2003, Luke A. Kanies wrote:
>
> > What problem is it a solution to?  Storing the entire config in RAM?
> > That's not much, and I'm not sure it's worth the extra effort.  I haven't
> > looked into this portion of the code, so I'm not really sure how it's done
> > or how much of a difference it can make, but I can't think it would be a
> > very large performance optimization.
>
> The problem is with dynamic class definition. At some point during the run,
> a 'define=dynClass' might add onto the list of currently-defined classes,
> say, as the result of a file being copied. If there's a
>
> shellcommands:
>     dynClass::
>       '/sbin/service restart daemon'
>
> in the configuration, out of parse order with the copy: class, it'll get
> skipped and never executed without the two-pass split. With AddInstallable,
> the parser can know that any action predicated upon a class in the A-I list
> ought to be delayed until the first pass is through. At that point, all
> the possible places it could end up becoming defined will have had their
> chance to do so.
>
> Simply reading it through (loading into RAM) isn't enough, you have to 
> actually
> *do* the non-predicated actions, for instance a define inside shellcommands:
> depends upon successful execution of a program outside cfengine -- it has
> to actually open the box, because whether the cat's dead or not determines
> whether we run it through the blender. (Or whatever.)

A double pass is the solution to that problem; that's essentially
unrelated to AddInstallables, isn't it?

My understanding is that AddInstallable is entirely a solution to the
problem caused by cfengine throwing away at parse time tests done on
classes that aren't currently set.  For instance, given the following
snippet:

files:
  /etc/inetd.conf checksum=md5 define=hupinetd

shellcommands:
  hupinetd:: "pkill -HUP inetd"

At parse time, "hupinetd" is obviously not set.  As a result, cfengine
throws away that test _at_parse_time_.

Then, cfengine actually executes, defines the "hupinetd" class, and then
doesn't do anything.  What AddInstallable does is say "hey, don't throw
tests on this class away if you see it".

In other words, the second pass and AddInstallable are unrelated;
AddInstallable is necessary because of a parse-time optimization, and the
second pass is necessary to make sure .  Mark will hopefully correct me if
I'm wrong, but that's my understanding of the situation.

Luke

-- 
I went to a restaurant that serves "breakfast at anytime".  So I
ordered French Toast during the Renaissance.     -- Stephen Wright