On (01/28/09 18:11), Peter Memishian wrote: > > > > so if we mandate that every operation must modify the peristent > > > repository and also track the corresponding undo_action > > > in a journal, then the "undo" for a create is to just move > > > the information from the persistent repository to the journal, > > > right? > > > > I don't think we're speaking the same language. The "undo" for any > > operation would have to take something from some hypothetical journal > > (no-one has specified whether this journal is the repository data itself > > or a series of commands that operates on the repository) and apply it to > > the repository. Not the other way around.
correct, and in the case of delete/modify, the journal for the "undo" operation has to be constructed from the repository information to construct the object (though I would postulate that the persist entry for the "delete" operation would itself be a noop). > > FWIW, I dislike the notion of building "undo" into the core admin model. > For one, it can fail. For two, it introduces its own dependency > complexities (e.g., if another administrative subsystem creats an object > "a" which has a dependency on "b" and b" needs to be undone at boot, > now coordination and complexity is needed to handle wha happens to "a", > and get the ordering right). > > The current dladm model isn't perfect but so far I prefer it to the other > approaches that have been floated. there's no perfect answer here. The snapshot solution has to deal with the issue of potentially taking a snapshot of someone's temporary configuration and unintentionally restoring it. And the a <-> b dependancy problem has to be addressed for all the solutions discussed so far (I would think even dladm needs to deal with it, as we add more and more features like vnics, aggr, tunnels etc to it). --Sowmini
