[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convergence and undoing changes

From: Ed Brown
Subject: Re: convergence and undoing changes
Date: Fri, 18 Nov 2005 16:23:55 -0700

On Fri, 2005-11-18 at 09:45, christian pearce wrote:
>   As you can see from the response you haven't gotten
> (i.e., none) people don't give a lot of thought and consideration to
> this.

I wouldn't say people haven't thought about the problem (even more
obvious now, than when I started to reply this morning): most of us have
had to deal with the situation and the questions that Viraj raised.  He
seemed to understand the issues on a practical level about as well as
anyone could.  Sometimes a lack of response just indicates the lack of a
real solution. 

'Undo' code is by nature one-time, one-off, and becomes meaningless
clutter after it's served it's purpose.  Cfengine can help us distribute
an 'undo', but it isn't what configuration management is typically
about, it's just happens to be something you can also do with cfengine. 
And simple good housekeeping practice suggests deleting it when it's no
longer necessary.  I'm not sure it should even be considered with other
policy or convergence considerations. 

Undo code can (should) include tests, to exclude the 'new host' or
'already undone host' situation where an undo isn't needed.

The question of 'one-time' actions with cfengine has come up before, but
not so much in this context of temporary undo's (distinctions being
things you would want to do on new builds too, and keep around
indefinitely).  Mark's suggestion from a year ago for one way to
accomplish 'DoOnce' actions could be useful for undo's too:

"You can define ifelapsed/expireafter times with a very long time
limits: ifelapsed=99999999"


While I'm always interested in hearing about what another tool can do
that what I'm using can't do, dissertations purely on what cfengine
can't do are mostly academic indulgence.  (Don't forget it can't wash
the laundry or take the dog for a walk either.  Actually, the list is
completely open-ended.)   Every implementation will teach you something
different about the capabilities and limitations of cfengine, but anyone
who works with cfengine every day has a very practical understanding of
what it's good for, and where it's not so good.  For all the talk about
"solutions" in the clarification of the pdf linked to earlier this
morning, I didn't see any at all, in either the pdf or the


"If you meet the "gold server" on the road, kill it!"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]