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://tracker.mender.io/browse/CFE-2512?focusedCommentId=76512&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-76512> 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/308b2ca2-75a5-4771-94f8-bcb70dd61299%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
