[Top][All Lists]

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

Re: convergence and undoing changes

From: christian pearce
Subject: Re: convergence and undoing changes
Date: Fri, 18 Nov 2005 14:21:31 -0500

On 11/18/05, Mark Burgess <address@hidden> wrote:
> On Fri, 2005-11-18 at 11:45 -0500, christian pearce wrote:
> > On 11/12/05, Viraj Alankar <address@hidden> 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:
> >
> >
> 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

reply via email to

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