Re: [Cfengine-develop] Development plan / meeting

[Chris (Ducky) Chapin]

On Fri, 28 Feb 2003, Luke A. Kanies wrote:

> I would _love_ to see a more sophisticated module interface developed, one
> which let anyone develop modules which could be configured similarly to
> existing cfengine sections.  Then, I'd really like to see most of the
> existing cfengine sections moved to modules, _including_ the core cfengine
> configuration stuff.  Just like how Apache has core modules for all of the
> config stuff.
> 
> This would require pretty significant modifications to the parsing,
> though, and it looks like it would be less than trivial to do this and
> maintain syntax compatibility.

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 would add a couple principles:
> 
> When possible, treat cfengine more like a language and less like a tool.
> This will make it much more generically useful, and will keep the design
> focused on providing the kind of consistency one expects in a language,
> vs. the allowed inconsistency of a tool.

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.
 
> Design to stay within cfengine as much as possible; if we find that people
> are doing things like autogenerating cfengine code, we need to figure out
> why and address the design decisions that are forcing that.  I find it
> remarkable how many people generate cfengine code, and how many people
> consider cfengine a basic building block but wouldn't consider using it as
> their main framework.

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.

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).

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

> > Many "complaints" are just not thinking straight.

And some of rest may be trying to fit cfengine to an environment that
didn't have cfengine in mind when it was designed. see above.

> I agree, but many complaints are also because cfengine makes certain types
> of operations far more difficult than they need to be.
>
> I think it would be very worthwhile for some of us to spend time combing
> the list archives and figure out what people consistently have to
> workaround, and then find ways to design those problems out.
>
> I personally find the lack of real lists, and especially the implicit,
> "sometimes" nature of lists, to be very frustrating and something that I
> often have to generate code to resolve.

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.

btw, I'm in San Diego, CA (PST/-0800).

-Ducky