I have been deliberately avoiding answering this because I am only keeping my head above water right now.
I'm sorry you're disappointed. I see several mechanisms working together. 1) dependencies 2) priorities 3) randomization More info will be forthcoming when the time comes. Hopefully I'll be able to make a start on 3 over the summer. M On Thu, 2005-05-12 at 17:02 -0600, Ed Brown wrote: > On Thu, 2005-05-12 at 13:35, Mark Burgess wrote: > > In version 3 I hope that all of this > > will be handled more elegantly. > > Another tantalizing, yet mysterious, intimation of better things to > come. One might start thinking you had a background in marketing! > > Perhaps my concerns will be moot when cfengine 3 changes our current > paradigms, but when discussions about the ordering of actions in > cfengine become discussions about dependencies, I am really > disappointed. While there is some overlap, they are different problems > really, and the change in semantics really changes the implications and > considerations. The last time dependencies came up as a solution to the > limitations of the current actionsequence implentation, it appeared to > me to be more of a nod to notions of PC-ness (Programming Correct-ness), > than directed at solving the problems of system administrators, i.e., > making cfengine even more flexible and easy to use. > > Brendan's [extremely well-articulated and demonstrated] examples for > using class dependencies are interesting, but I'm not convinced that's > the answer to actionsequence limitations. Imagine trying to implement > your current actionsequence in terms of class dependencies! Granted, we > might not care to reinvent the actionsequence, and sequence might not > matter for much, even most, of what cfengine does. (But knowing it is > determinate, and how, is often useful and important.) > > To me, it would be vastly easier, more powerful, and more flexible, to > simply assign a priority to an action (or not, if it doesn't matter), > and know immediately how it relates to ALL other actions, rather than > have to define any relationships individually. I don't have to worry > about breaking dependencies, or finding/fixing/maintaining relationships > across many config files. It's easy to understand at a glance for the > human and the machine parser. Multiple passes aren't required... (And > concerns, if there are any, about performance optimizations that a > dependency-based approach might offer, in my typical <10 second cfagent > run, would be way at the bottom of my list.) > > Frankly, I prefer the status quo, to a solution based on defining > dependencies, at least as I understand the idea now. > > -Ed > > > > _______________________________________________ > Help-cfengine mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/help-cfengine _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
