Paul Krizak 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 thou
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.
Paul Krizak
On 9/13/10 12:20 PM, "Paul Krizak" wrote:
> I can see the advantage to using a persistent class in this case. It
> allows you to have different timeouts for different events. If the wget
> fails, the "I failed to wget" class can have no persistence (so the next
> 5-minute run will try again) whi
I can see the advantage to using a persistent class in this case. It
allows you to have different timeouts for different events. If the wget
fails, the "I failed to wget" class can have no persistence (so the next
5-minute run will try again) while the "I was able to wget" class may
have a pe
no-re...@cfengine.com writes:
> Persistence for the sake of it. I can't argue that. Perhaps attempt
> the wget command, and upon failure set a persistent class. However, I
> can't see much benefit to this versus using ifelapsed to limit my wget
> promise to once every four hours.
Yeah, that ma
no-re...@cfengine.com writes:
> Forget all about classes and persistence for a moment. What are you
> trying to accomplish above that?
This isn't about accomplishing a defined task, as much as learning
Cfengine and designing a clever framework for later use. Sorry to
dissappoint, but for now per
no-re...@cfengine.com writes:
> I think you want to change the class strcmp to a command action
> instead. Then define the class as repaired or not.
> http://www.cfengine.org/manuals/cf3-solutions.html
Thanks Neil. I've been playing around with this. However, I'm a bit
stuck. I have a command th
