On 11/18/05, Mark Burgess <[EMAIL PROTECTED]> wrote: > On Fri, 2005-11-18 at 11:45 -0500, christian pearce wrote: > > 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 have not seen this before. In fact it annoys me a little because it is > factually incorrect and seems just to be an unnecessary slur on > cfengine. I would not expect that from Alva. There is plenty to > criticize in cfengine 2, but it does not help to misrepresent its > behaviour. This network level divergence example is highly misleading. > Of course there can be periods of divergence, but the talk seems to > imply that some other tool could improve on the problem. In fact I would > suggest that no other tool provides more consistency than cfengine > today.
hmm as I was not there I am not certain what to make of the presentation. I certainly am not trying to throw mud. I should have stated that others have given thought about this, and the term "implicit divergence" is the result of no longer managing policy on a given machine. So if you choose to ignore that policy, then all new machines vs. old machines technically have a different configuration. I think what he meant by network divergence is that when manage undo policy with Cfengine, machines that are off line that don't get the update become susceptible to losing step with your policy. For example if you choose to undo a file, how do you know all your machines reported in and implemented the policy? (I suppose you could do a cfrun, but this require human intervention) If you then took out the policy that undid the change (so you can implement new policy in the same space) some machine might then come back on line and be in a state the your policy is not capable of handling correctly. This doesn't mean the tool is broken, it just means you have to give careful consideration to the policy changes you are making. Maybe Alva can chime in with a specific example that he observed to make this assertion. This is easily solved by creating state, (and Mark I know you are going to disagree with this) for the undo policy. Touch a file and then create a class if that touch file exists. If that class exists then you know the undo policy happened and you can progress with the new policy that has to exist in the same space. If it doesn't exist then send out and alert and go solve the problem by hand if need be. > Cfengine does not have a rollback function, because that would require > it to remember everything about the previous states (which state is > that?). It requirs exponentially growing memory and has no obvious > versioning control. There is currently no fully predictable solution to > this problem except to reprogram the state you want as if it were a > forward change. Also how to do you rollback changes where data was modified. These are sticky questions. While I think rollbacks could be implemented in cfengine it might not have the desired results. -- Christian Pearce _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
