On Wed, Dec 14, 2011 at 05:28:10AM -0500, Marco Marongiu wrote:
>Hi
>
>I can't be as specific as lauwersw. I've been a cfengine2 user for some
>time, but my experience with cfengine3 is still too small.
>
>1) So, on a general note, and resuming what I already said in other
>threads, simple file editing is sometimes too hard. E.g.: placing pieces
>of text in a very well defined position inside a file is too difficult,
>and template files are too feature-poor to be 100% feasible.
>
>For computers, it may not matter where a comment or a configuration
>directive is placed inside a file. But configuration files are also read
>by humans, and providing comments and directives in the places a human
>expects them to be _is_ important. Placeholders or pseudo-tags are not
>the solution: they are workarounds, and may make a file more difficult
>to read.
I'll 2nd this as well. It seems that the overall functionality of file
editing has gotten *worse* in CF3, relative to CF2. I realize that
there may be issues with convergence, but I think there is quite a bit
of room for improvement in the current implementation as well.
>2) Documentation as a whole is not easy to use. We have:
>
>* a bare-bones tutorial (too bare bones be really useful)
>* a complete reference (a bit less than 600 pages...)
>* a standard library reference (i.e.: the "Cfengine Open Promise Body
>Library" reference)
>* a best practices guide
>* a number of "Special Topics" guides (more than 30)
>
>Guess yourself how easy is to find the right path through all these
>documents. A reorganization is definitely needed, and a better, richer
>tutorial is, too.
I'll actually put in a *good* word for the the reference manual, in that
it *is* comprehensive. Overwhelming and hard to use as a learning tool
to be sure, but it is mostly complete. (Given the choice between a full
reference and a tutorial, I'll take the reference.)
That said, I think that a lot of the smaller examples for attributes
body attributes, functions and variables need to be a lot longer. This is
especially true for functions like canonify(), classify() and the like.
The entire block of ${mon.*} variables as well. The explation for all
of them reads something like:
"Observational measure collected every 2.5 minutes from cf-monitord,
description: %CPU utilzation 3."
Nor is there much explanation about different dev_*, value_* and av_*
variables, or how to use them, or what they actually mean.
(That said, if anyone is interested, I've tried posted this page to help
see what values are recorded:
http://cfengineers.org/wiki/index.php/Mon.*_context_variables)
>3) Maybe connected to the previous problem: the language itself is too
>complicated for beginners. It would be nice to have sort of a simplified
>language (cfScript?), and a compiler to translate it into cfengine3
>native policies.
I'm not sure that introducing an intermediate language is a good idea.
Now we have yet another language to learn, and haven't fixed any of the
fundamental syntax problems that already exist.
Of course, there are some pretty strange by oddities in the language,
which does not help matters.
Some places have constructs that "look like strings", but do not follow
the rules for string interpolation. Examples include defining variables
and classes, for example. It'd be awfully handy to do something like
this:
vars:
'list' slist => { 'foo', 'bar', 'baz' };
classes:
"Has_${list}" => isplain("/tmp/${list}");
Some intrinsic values are strings, others are not. I don't know how many times
I've been tripped up by the two errors in this snippet:
files:
"/some/file"
perms => "paf", # WRONG! should not be quoted
create => true; # WRONG! should be quoted
One is an intrinsic, and needs quotes. The other is a user-defined
body, and doesn't. That's backwards from what I would normally expect.
Integers, floats and strings are considered different data types, for no
obvious user-level reason. At a high level--the global infrastructure
systems administration, datacenter management level--these distinctions
are arbitrary and more than a little strange. If we were dealing with
low-level libraries, I'd have a different view of things, and indeed
the underlying C code should care a great deal about about it. But the
cfengine promise language should not.
List and arrays are granted "second class" status. Using them is
difficult, outside of trivial list iteration, and anything more than a
basic list or associative array is impossible to create. It is very
confusing when a list should be dealt with "as a list" or "iterated over
as individual items". This leads to *very* messy and unmaintainable
code.
The rigidity of bodies and bundles is incredibly frustrating, and
inflexible. Take 'classes =>' bodies, for example
(http://cfengine.com/manuals/cf3-reference.html#classes-in-_002a).
There are 13 different options that are possible in this bundle.
Between the bodies defined in cfengine_stdlib.cf and my own library.cf,
I have 13 different bodies to express slightly different things. Why
are these two different bodies needed?
body classes if_ok(x) {
promise_repaired => { "$(x)" };
promise_kept => { "$(x)" };
}
body classes if_ok2(x, y) {
promise_repaired => { "$(x)", "$(y)" };
promise_kept => { "$(x)", "$(y)" };
}
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
