Re: convergence and undoing changes

[Mark Burgess]

> 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.

I think our point of departure in thinking in that such a consistency is
ever realistically possible in any scheme, with any tool. I believe
fundamentally that one must expect and deal with variability/uncertainty
in a network. Alva, you are trying to eliminate it. I just think that is
flogging a dead horse. That does not mean that the discussion is not
worth having, but one needs a more balanced perspective when throwing
mud.

The problem with the example in your slides is that it does not show
that, under cfengine, when down-machines come up again that they WILL
NORMALLY converge to the same final state as the others -- they have NOT
missed out on the changes as the examples implies. You are correct
however in pointing out that users CAN screw this up by trying to be too
clever, by not thinking convergently. But that is not the normal state
of affairs.

M