Hey Mark The most difficult time I had with Cfengine was going from nothing, to having network transfers working. Once I understood the concepts of failsafe.cf / promises.cf, things started to make sense and building upon that base configuration was pretty straightforward. I know that you guys are shipping sample configs now with the source code. What I would suggest, is to create a new "users guide" that went through step-by-step and line-by-line to describe what exactly was happening in those basic configs and why..
Then, since "sharing policies" is such a taboo subject for whatever reason (we all really need to work on sharing some of the best / coolest things we're using Cfengine for) — actually include in that base configurations some policies to do stuff. Not just the unit tests. Lets show snmpd or ntpd being configured and daemons bounced. Show command execution. Show file changes. Show file changes raising a class, which is used to execute a command and then fire a report.. Show an example of how processes / linux services / packages / template substitution works. We've all submitted some of our policies to this mailing list. Lets collect a few of those examples and include them in this new users guide. The RHEL6 services policy and /etc/sysctl.conf policies that I submitted I think would be a great introduction as long as they're explained. Once you provide those policies, then spend a few pages explaining what design decisions happened behind them. Once you are able to show policies and explain exactly whats happening in them, I think the learning curve of Cfengine will decrease. You'll have less frustrated folks, and I think newbies will start doing things "the right way" by having Cfengine execute promises as designed. I think a lot of people are using Cfengine as a distributed platform to launch shell scripts because they just don’t want to learn / deal with what Cfengine is. If we show policies and explain the design decisions behind them, the n00bs are going to have a better experience. I wish the recent Cfengine 3 book did this. I begged them not to publish what they were putting out, because just throwing Cfengine policies / config is worthless unless there is some meaningful discussion behind what this stuff actually means. Thanks Mike From: Mark Burgess <m...@cfengine.com<mailto:m...@cfengine.com>> Date: Sat, 17 Dec 2011 14:58:59 +0100 To: <help-cfengine@cfengine.org<mailto:help-cfengine@cfengine.org>> Cc: "develop...@cfengine.com<mailto:develop...@cfengine.com>" <develop...@cfengine.com<mailto:develop...@cfengine.com>> Subject: (addendum) How easy/simple is cfengine? Addendum: Sorry again for forgetting the link http://www.infoq.com/presentations/Simple-Made-Easy It is worth commenting on two ways in which this talk applies to CFEngine, (in my personal view). What I like about the talk is that it is not dogmatic, but poses questions. The speaker says that certain things are good and bad, but does not claim that certain bad things are unavoidable, only undesirable in a perfect world. CFEngine was needed because we don't live in a perfect world. The talk is about how to limit it to what is "necessary and sufficient" and it applies to CFEngine at two levels: 1. the design and principles used by CFEngine for the problem of modelling configuration e.g. CFEngine's language design seems to satisfy all the speaker's requirements for simplicity. With reference to the inline body-syntax we discussed recently in the forum, I believe inline syntax complects "what" with "how" by abusing syntax to mis-represent information (that puts it strongly to underline the point). The speaker suggests that one should *try* to avoid complexity, but CFEngine's job is to cope with / model configuration complexity that others have created, i.e. (state) in a simple way. The disciplines it brings encourages users to design simplicity, making things more declarative and non-intertwined (autonomous) and eliminating imperative threads that complect what with how. This complexity cannot necessarily be removed (there is a concept of necessary and sufficient complexity), so we should not *oversimplify* a model. We try to cope by imposing a simple discipline on the representation of state by disentangling independent issues into promise types with body types, using a meta-model called "Promises", together with the concept of convergence (persistence of state). 2. the internal design of CFEngine's implementation. In writing CFEngine 3, the use of the promise model led to considerable disentanglement of code, compared to CFEngine 2, though there might still be parts in the lower subsystems that could be further disentangled. It was necessary to have a model to understand how to disentangle issues. In my view Puppet more deeply entangled the modelling issues, sacrificing simple for easy. It would be an interesting exercise for the development team to discuss how the principles the speaker expounds apply to different parts of the code. Personally, I would have liked to hear what the speaker had to say about global data/variables, since this is an area where I noted the speaker's words (paraphrased): "Let data be data, don't hide it behind an API" with agreement. I read this as an argument that global data/variables have a valid place in programming, as long as one copes with the inevitable changes of state. M -------- Original Message -------- Subject: How easy/simple is cfengine? Date: Sat, 17 Dec 2011 10:09:12 +0100 From: Mark Burgess <m...@cfengine.com><mailto:m...@cfengine.com> To: help-cfengine <Help-cfengine@cfengine.org><mailto:Help-cfengine@cfengine.org> Mikhail, one of our very brilliant developers, recently brought this talk to my attention. I just had time to look at this and it is very good. The talk is a most excellent discussion about making choices about easy versus simple in software. I recommend everyone to watch this and absorb its content. It is very relevant to the discussion about making CFEngine easier/simpler, also vis a vis the choices made by Puppet/Chef versus CFEngine, etc etc - and I very much agree with the speaker's viewpoint. He does not provide any answers, but he poses important questions: the best kind of talk. M PS - Category theory (re: monads) is a form of mathematics, akin to set theory which is often used to explain anything by pulling the wool over people's eyes :) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org<mailto:Help-cfengine@cfengine.org> https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
