On 11/12/05, Viraj Alankar <[EMAIL PROTECTED]> 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 _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
