Moore, Joe wrote:
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)
An interesting idea. One could think about this as exceptions that can
be raised during one cfagent run and handled in a subsequent run.
We might be able to do this now with:
SetState("preserved_class",10,Preserve)
SetState(non_preserved_class,60,Reset)
UnsetState(myclass)
(See http://www.cfengine.org/docs/cfengine-Reference.html#alerts )
All those are used in the "alerts" sections, which would just be weird
to use for what you discuss above, not in the least because "alerts" is
one of those magic non-actionsequence actions.
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine