Sharing policies is not a taboo subject. It is just something that few
people seem to be willing to do. We can only keep trying to offer the
right forum.
M
On 12/17/2011 05:54 PM, Mike Svoboda wrote:
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>
To: help-cfengine <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
