Paul Krizak <paul.kri...@amd.com> writes:
> I think the value in this case is less in the simplicity of the code,
> and more in the fact that it allows you to fully document the
> intentions/behavior of a given promise without having to resort to 3rd
> party code, i.e. the promise becomes self-documenting.
My thoughts exactly. Why outsource to external scripts when Cfengine can
do the job. While for now this is merely of theoretical interest to me,
I can imagine real-life scenarios where class persistence may prove to
be a useful feature.
>From what I can gather about persistent classes, it is designed for
classes that are generated on-the-fly, e.g.:
# This works:
commands:
"/usr/bin/test -e /tmp/foo"
classes => persist("foo","10");
# This does not work:
classes:
"foo" expression => fileexists("/tmp/foo"),
classes => persist("foo","10");
persist() is defined as a classes body:
body classes persist(class,time)
{
promise_repaired => { "$(class)" };
persist_time => "$(time)";
timer_policy => "reset";
}
I have yet to find a way to set a class persistent, if that class is
created with a function that returns class, like fileexists() in the
example above.
Cheers,
--
Trond H. Amundsen <t.h.amund...@usit.uio.no>
Center for Information Technology Services, University of Oslo
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
