Re: convergence and undoing changes

[christian pearce]

On 11/12/05, Viraj Alankar <valankar@gmail.com> wrote:
> I'm a little confused on how to deal with undoing changes in a
> convergence methodology. Let's say I decide to push a file
> /usr/local/bin/foo to all of my servers. Then I decide not to do this,
> and take it out of cfengine. This will be correct for new servers
> 'converging,' but not the current ones which still have the file. Is
> the normal procedure to have cfengine remove the file if it is there?
> But then that removal is unnecessary on new servers.
>
> Or is a better method to make cfengine undo the changes temporarily,
> and remove this 'undo' configuration once all of the old systems are
> fixed?
>
Alva Couch gave a presentation about this:

http://homepages.informatics.ed.ac.uk/group/lssconf/config2005e/Slides/cfengine.pdf

I didn't see the presentation first hand.  This is what he calls
"implicit divergence".  The best thing you can do is tell Cfengine to
undo the change.  And then you can leave the policy in place.  Or you
can remove the policy once all your old servers have picked up the
change (not easy to tell how though we can talk more about this if you
like).  I by default always associate policy with a group (or class)
and further separate each chunk of policy into a separate import. 
This gives me a clean and clear view of what policy is effecting
change of a given group of machines.

It is just a matter of decision on your part.  If leaving the file
there doesn't hurt anything then so be it.  Do bother with it.  If you
need to remove then do so.

> This is a simple file copy example, but can be extended to other
> complicated tasks (editfiles, etc). I'm wondering how others approach
> this problem. I just envision getting into a situation where there is
> a ton of 'undo' code that becomes unwieldy. I understand it would be
> best to avoid needing to undo anything, but that may not always be
> practical.

It gets complicated quick.  Documenting what you do is obviously
important.  I recommend that people have a standard operating policy
written in natural language.  Then you correspond that with written
cfengine policy.  Once you no longer need that policy then deprecate
it in the docs.  Write the undo code and push that policy out.  The
undo code shouldn't be hard, it is just automating what you would do
one the command line.  If the Cfengine language isn't rich enough just
move it into a shell script.

Hope this helps.  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.
--
Christian Pearce