Re: [Cfengine-develop] Development plan / meeting

[Luke A. Kanies]

On Fri, 28 Feb 2003, Chris (Ducky) Chapin wrote:

> Well, I was going to comment on all this, but I kept noticing you'd
> already said what I wanted, so all I could come up with was a very
> unintelligent, "ME TOO!"

:)

> I think something to keep in mind is cfengine already is mostly a language
> - it just happens to have some higher level, hard-coded functionality.

Right, I'm aware of cfengine's dual personality; my point was that if we
focus more on the language aspect of cfengine, we'll have a more flexible
and thus more usable tool.

> Exactly. In my environment we have 2 distinct types of classes, one of
> which, we call "clusters" distictly groups hosts, usually to a unit -
> hosts may belong to only one of these. The other, called "duties", does
> not have the, "only one per host" limitation.  We have 146 clusters and
> 406 duties.

I'm currently having some luck integrating cfengine and isconf; using
isconf to do all of the heavy lifting, and then using cfengine to do
verification and such.  It's not totally implemented, but I like it so
far.  I'd love to be able to configure ISconf within the cfengine configs,
though, rather than just calling it as a shell script, basically.

> Managing all these classes in a cf would be an absolute nightmare, so we
> use plain text files local to the host to define membership. But I kept
> running into issues with trying to shoe-horn cfengine to accomodate this
> model - modules don't get run soon enough, missing/not-yet written configs
> for duties/clusters would make cfengine abort - which lead me to shell
> scripts to write cfengine configs and finally cfengine dying because I had
> too many classes (buffer overflow).

One of the things that struck me initially about cfengine, and still is
true, is that it's difficult to figure out what happens at parse time,
what happens at runtime, and where everything else happens.  I think part
of the source of this problem is that most of the work of parsing and data
type instantiation actually takes place in the lexer, which means that it
happens very early in the process.

I think one of the first things that needs to be well documented is
exactly what happens where in cfengine's processing.  If you look on page
178 of the bash book, for instance, there is a diagram which goes through
bash's exact processing method.  Looking at this description, you can take
a bash command line and figure out exactly what's going to happen and
in exactly what order.  No such documentation exists for cfengine, and in
fact I think it would be difficult to come up with it, because the runtime
and parsetime aspects of cfengine are mixed pretty thoroughly.

> It was a sad day when I told management we'd couldn't use cfengine in our
> environment as the both exist. =(

I'm using it, but not very much at this point, and I'm hesitant to try
using it for much beyond file permissions, process lists, and a file
transport.

> I'm confident a good portion of the problems like "sometimes" lists and
> module-defined variables not being able to be split, would start to fix
> themselves with a more language-driven model.

Yeah.  I actually think that the parser has the most opportunity for
improvement, and will get us the ability to add features the fastest
while staying consistent.

OTOH, I have never written a language before, so I'm not exactly speaking
from a position of authority.  Also, I was surprised to find when looking
at perl as an example that perl uses its lexer for significant amounts of
its parsing.  Somehow perl does so in such a way that parsing order and
the differences between parsetime and runtime remain very clear, so
there's assuredly a way to do the same thing in cfengine.

Luke

-- 
It has recently been discovered that research causes cancer in
labratory rats.