On Behalf Of Tim Nelson
> The above makes sense to me. But say I have things
> that are in a
> particular order at the moment, how will I be able to ensure
> that they're
> still ordered with cfengine 3?
Just throwing something out here, but if the system state is dependant
on a particular ordering, doesn't that say something about the
convergence of those rules?
I guess what I'm saying is: "Why does ordering matter in a convergent
system?"[0] -- we know we'll run the shellcommands sometime during the
next cfengine pass/invocation (to restart inetd, for example).
Convergence guarentees that after this pass, the system will be in a
"better" configuration.
The trouble comes in that state is not preserved across cfengine
invokations. The restart_inetd class that's defined when you editfiles
/etc/inetd.conf won't be defined the next time cfengine runs.
So one option for cfengine3 could be to preserve more state, and have
actions explicitly clear that state... idea: classes that are defined
by an action (using the new "set" keyword) are kept until they are
cleared. (this might be implemented by a state DB or by giving them to
cfenvd)
<conceptcode>
editfiles:
{ /etc/inetd.conf
AppendIfNoSuchLine "#Hello World"
set=restart_inetd
}
shellcommands:
restart_inetd::
"/etc/init.d/inetd restart" clear=restart_inetd
</conceptcode>
--Joe
[0] Traugott et al.'s
http://www.infrastructures.org/papers/turing/turing.html notwithstanding
_______________________________________________
Help-cfengine mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-cfengine
