On 4/1/06, Edward F. Brown <[EMAIL PROTECTED]> wrote: > O Fri, Mar 31, 2006 at 03:32:22PM -0800, Atom Powers wrote: > > > "undo" means "un-do": reverse what you did. > > I think this is simplistic.
And I think you are overly complicating the problem. But I think we will have to agree to disagree. >To try again with the example of > changing modes on a directory, say recursively setting modes: > how do you undo this action unless you maintain extensive > state information about the modes beforehand? You can't get > around maintaining state information if you expect to > implement an undo function. You don't need state information, you only need the delta or a changelog. If you know what state it /should/ be in you write a rule for that. If you want to know what state it /was/ in you you simply reverse the last change. >How long do you > maintain this info? What does this 'memory' of the way > things were mean beyond the present transaction? Things > change, and you might consider such changes beyond the scope > of the tool, but I don't see how 'undo' could ever be > convergent or reliable (guess that's redundant). Ah, here is where we differ. I don't expect undo to be convergent, I only expect it to undo the last one or few changes. If I wanted convergence I would write that into a rule set. For undo I only want the ability to fix "oh crap, I didn't mean to do that" situations. > The path forward may be as simple as reverting to a previous > configuration (that's why version control is important). Not unless you maintain the entire system with your rules set. Reverting to a previous config. would certainly not be able to fix "InsertIfNoSuchLine" or just about any other rules for that matter, especially if they are new rules. While a change log would be able to tell you if a line was inserted even if this is no previous configuration. > But it has to involve thinking, and new configurations, the > same process used in initially shooting oneself in the foot, > even though that may not offer a real [good] solution (you > probably don't remember what the modes were initially on > all those files and subdirectories either). Right, which is why the change log is so important. Current State - Last Change = Previous State. Granted, this can't apply to user-modifiable files; but at least you should be able to undo the last configuration change made by cfe. And frankly, user modifiable files probably shouldn't be in your configuration anyway, unless you take special measures to preserve the user generated changes. > As appealing as the idea is, and maybe it's shortsighted of > me, but I think 'undo' will remain an academic notion, from > the how-to-save-a-sysadmin-from-him/herself school of > thought. My position is simple: the tool should be able to undo what it did; if you want to preserve user modifications get good backups. Perhaps you can combine the two to make your undo convergent, but that is a different problem. > Have any other tools addressed 'undo'? I think I head that puppet is working on this, but frankly I haven't even looked at it yet. > -Ed > -- -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org http://cfengine.org/mailman/listinfo/help-cfengine
