Hello all; I apologize for breaking into this conversation but this is one of the few conversations I found discussing CM tools in the context of Promise Theory.
I have just been looking into various CM tools (currently use Puppet) and started reading about CFEngine and Promise Theory. I after reading a few articles and watching a few videos I'm still not sold or not fully understanding the implication of Promise Theory. Here is the text from a post I made on one article. Please clear up any misunderstandings or incorrect statements that I may have made: The idea of each actor or node being autonomous seems somewhat farfetched in reality or an abstraction at best. The theory is explained such that these actors make their promises and coordinate amongst themselves. It is differentiated from obligation in that the actors supposedly can't be 'told' what to do. However, even though such systems are written in a declarative style these are still effectively 'instructions' and not 'requests'. The actor really doesn't have a choice of whether to execute them or not. Unless, of course, the particular node doesn't have a relevant operation to support the request. Furthermore, it seems to me, that the distinction between imperative and declarative is fuzzy. Yes, we write our configuration in declarative language but ultimately the agent on the node implements our declarative requests using predefined imperative routines. The actors have no true intelligence other than being written specifically for a particular platform and executing routines that are relevant to those platforms. The declarative style is, therefore, simply an abstraction that prevents us from having to write instructions toward a specific architecture. Probably the use of agent-based solutions lends itself to better scaling but I feel that this trying to fit the operation of it all into the fancy formalized box with specialized dialect just over-complicates things for the average administrator. On Sunday, November 27, 2016 at 11:33:34 AM UTC-6, Mike Weilgart wrote: > > Hello, > > I want to take a moment to talk about CFEngine adoption *far, far forward* > into > the future. > > Promise Theory is an extremely brilliant mathematical model on which to > base configuration management. CFEngine was the *original* configuration > management software, and it's noteworthy that all its competitors have > copied the notion of convergence and contain some aspects of a declarative > language. However, CFEngine 3 is much closer to a clean implementation of > Promise Theory than any other software existing today, and has this as an > "edge" over its rivals. > > ------ > > After working for over a year with CFEngine in an enterprise-scale > environment, training technical personnel in the writing of CFEngine > policy, driving executive adoption of CFEngine and its enterprise reporting > UI, and comparing CFEngine to its competitors as well as to its underlying > Promise Theory—the obstacles I see which must be dealt with to *ensure > CFEngine's long term survival* are as follows: > > *1. The learning curve.* More explicitly, the lack of easily > understandable and easily searchable documentation. Effort must be > explicitly exerted to make CFEngine *easy* to get started with for > newcomers. As a community, we need to actually put attention on "number of > users of CFEngine" as a statistic which must be increased. > > This is the factor which trumps everything else, as if there *are users*, > there will be new developers, there will be improvements, there will be > adoption. > > (This is sometimes referred to as "Worse is Better," > <https://en.wikipedia.org/wiki/Worse_is_better> which is really not true. > The valid point underlying that statement is that regardless of how > *good* your product is, unless it is *used* it will not survive and > thrive. It is possible to be excellent *and* be widely used.) > > *2. CFEngine's adherence to Promise Theory.* > > The primary advantage of CFEngine over its competitors is that it is > firmly rooted in a precise mathematical model which closely mirrors the > reality of configuration management. > > Configuration management products which are not based on any coherent > theory may be widely used at the present, but their viability *long term* is > closely related to how accurately they are based on a workable approach (a > workable *theory*) for the problem domain to which they are addressed. > > The greatest threat to CFEngine's future survival (spanning multiple > decades) is its potential violation of its *fundamental purpose*, which > is to apply Promise Theory to computer configuration management. More > bluntly, if CFEngine is to stand the test of time, it must adhere much more > closely to Promise Theory at every level of its design and implementation > than it currently does. > > This relates to the first point above, as reading the current CFEngine > documentation will not give a newcomer *any* insight into Promise Theory. > > I believe that Promise Theory is an extremely accurate model and a > workable mathematics, and that a product or language which cleanly > implements that mathematical model will be, and remain, successful. > > ------ > > This brings me to the purpose of this email. > > CFEngine may be regarded conceptually as consisting of three distinct > parts: > > 1. The underlying theory and mathematical model (Promise Theory); > 2. A conception of how that mathematical model may be applied to the > subject of configuration management; > 3. An implementation of the ideas in (2) as a software product. > > Part 2 may appear unfamiliar. That's because it doesn't truly exist > *currently* as a distinct entity. Part 2 should consist of a *language > specification* for the CFEngine policy language. > > Right now there is only one interpreter for CFEngine policies. As such, > there is no clear differentiation between the *language* *itself* (as a > means of representing concepts, ideas, intentions, configuration states) > and the particular parser for that language known as CFEngine Core. In > other words, there is no distinction between the *language* and the > *implementation*. > > It is particularly important for a declarative language to have a > clear-cut *specification*, as the concept embodied in CFEngine *is* that *you > should not concern yourself with the procedural, sequential steps by which > CFEngine will achieve the end state you specify—you should define the end > state and CFEngine will make it so*. (I wrote about this elsewhere > <https://www.google.com/url?q=https%3A%2F%2Ftracker.mender.io%2Fbrowse%2FCFE-2512%3FfocusedCommentId%3D76512%26page%3Dcom.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel%23comment-76512&sa=D&sntz=1&usg=AFQjCNEu_fZuV3qkX_cbWJhoUeAGwFawig> > recently, > though perhaps not so clearly.) > > Anyone who has worked with CFEngine 3 policies at scale for any length of > time knows that this ideal has *not* been achieved in CFEngine 3. There > are innumerable ways in which one must tweak and adjust the sequence of > promises, specify procedures, and work around implementation flaws to > achieve the desired end state. > > For example, if one has mutual promise dependencies (of different promise > types) within a bundle which exceed the arbitrary three-pass limitation in > CFEngine Core, the final promises in the dependency chain will *never* be > evaluated > <https://gist.github.com/mikeweilgart/79f814e2b11c1f05c01fc0ba9ff0ea64>. > This is both documented behavior and has possible workarounds; that's not > the point. The point is that it is an *implementation detail* that a > policy writer *must* take into account, or the results will be totally > unexpected. Thus it violates the principle of simply *implementing > Promise Theory*. > > ------- > > *To implement Promise Theory directly as a configuration management > language will not require drastic changes to the CFEngine policy language.* > > However, establishing a language spec *will* change the expected behavior > of all existing policies written for CFEngine 3, if only because they are > so closely tied to implementation details as to leave no "wiggle room" to > establish a spec that is backward compatible *and* future compatible. > > More bluntly, existing policies are so inextricably intertwined with > implementation details that most of the current execution results *should > be* undefined behavior in a well-written spec. > > I made a brief start > <https://tracker.mender.io/browse/CFE-2512?focusedCommentId=76512&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-76512> > > at writing such a language spec, which may illustrate better what I am > expounding. > > ------- > > (In actual fact, there should probably be a fourth ingredient beyond those > enumerated above: In between the underlying theory and a CFEngine language > specification [in between (1) and (2) in the earlier list] should come a > directive establishing at a high level what features a language *should* > include (and *should not* include) in order to truly reflect and > implement Promise Theory. This would be a document for Promise Theory > serving the same role as The Third Manifesto > <https://en.wikipedia.org/wiki/The_Third_Manifesto> serves for the > relational database model. But that's not quite so pertinent for the > CFEngine Dev's mailing list.) > > ------- > > What is *your* response, as a CFEngine developer, to the ideas laid out > above? Shall we work toward a more precise language specification for > CFEngine 4.x? > > Thanks for your time and attention. > > Best, > --Mike Weilgart > Vertical Sysadmin, Inc. > -- You received this message because you are subscribed to the Google Groups "dev-cfengine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/aaf00b39-38a1-49b4-b55b-68a22575f717%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
