RE: Ordering and cfengine 3 (was RE: Is this quirky for asimple copy, editfiles operation?)

[Moore, Joe]

On Behalf Of Ed Brown
> On Fri, 2005-05-13 at 12:21, Brendan Strejcek wrote:
> > We could do both. :-) It might add more robustness to cfengine if
> > unsatisfied dependencies were preserved between runs. What if the
> > cfengine run is cut short before it completes all the necessary
> > passes? I don't think that we can assume that cfagent will 
> be able to
> > complete all of it's tasks before being cut short by an 
> admin running
> > "/etc/init.d/cfengine stop" or some timeout causing aborts.
> 
> This brings me around again to how the concept of 'dependencies' is
> striking off in a very different direction than required by 
> the simpler
> problem of adding flexibility to sequencing of actions.  It's a
> feature-add really, and raises a host of new questions.  For example,
> there is no 'unsatisfied actionsequence" problem, precisely because
> there are no dependencies.  

Rather than thinking in dependencies, I think it would be better to
think of it as a response to the state of the system:
Editing /etc/inetd.conf moves the system into the state "needs to
restart inetd".  Shellcommand "/etc/init.d/inetd restart" brings the
system out of that state.

> As for setting state for an 'unsatisfied' dependency, what do 
> you do if
> that class is NOT set in subsequent runs, perform the action anyway? 
> What do you do if it IS set again, perform the action twice? 

If the class is not set, then the action doesn't happen (because the
admin has made it conditional on that class).

If the class IS set, perform the action and (on success?) clear the
class.  Every time the system is in the state "needs to restart inetd",
the right thing to do is to run that shellcommand.

--Joe