Re: [Cfengine-develop] Development plan / meeting

[Luke A. Kanies]

On Mon, 3 Mar 2003, Mark Burgess wrote:

> > Mark, can you speak on what your design goals are?  Should our first
> > conclusion be what role we specifically see cfengine playing?
> >
>
> Cfengine should be as plug'n'play as possible, with as much flexibility
> as possible. It shouldn't be for gratuitous monitoring -- it should keep
> as quiet as a mouse and work as autonomously as possible.

Hmm, I don't consider much monitoring to be "gratuitous".  It's pretty
important to me that all of my services are running correctly, and if I
can use a single framework to both configure and verify (which is
basically the same thing as monitoring) my services, why shouldn't I?  It
seems like less work, not more.

Is there anyone out there who isn't planning on implementing some kind of
monitoring?  You've got to have something; why not use cfengine for that,
since it seems a natural fit in terms of functionality?

And I certainly don't see how making the ability to monitor an explicit
part of cfengine's feature set makes it _less_ flexible and _less_
plug'n'play.  "If I've got dns configured, make sure it's always running."
"If I've got a host configured, make sure it checks in at least once every
hour."  That kind of stuff; it's all there, we just need some hooks to be
able to set up what's currently missing (which isn't actually much).

> See
>
> http://www.cfengine.org/Cfengine2/1.html

While I applaud simplicity, it's very much a qualitative goal.  It would
be possible to use cfengine without ever using variables, which one could
argue is more "simple", but that would make managing cfengine more
difficult, which I would argue makes it more complex.

Simplicity for whom?  The developer?  The administrator?  The computer?

I think the goal of any administrative system should be to have the
computer do the most work, then the developer, and to have the
administrator do the least work.

If everyone's going to have monitoring anyway (and they all should, even
if they don't), then wouldn't it be simpler for the administrator to have
that built into cfengine?

> > For me, I would like it to be a framework, but it's more of a tool
> > right now.
>
> Luke, I don't understand you. In what way is cfengine NOT a framework?
> What do you think is missing?

Well, like I've mentioned earlier, I see a lot of people generating
cfengine code, rather than working within cfengine.  My definition of
framework is basically that it sits above everything else, and if you're
generating your framework using another tool, then you've got something
sitting above your framework, which by my definition makes it not your
framework.

I understand that not everyone is generating cfengine code, and I expect,
Mark, that you are not generating it, but nonetheless, many people are.
Alva Couch has said many times that he considers cfengine to be not a
framework, but the bottom level of a configuration management system,
relying entirely on generated cfengine code, often times generated in
small increments at run-time.

What is it about cfengine that makes people have to generate cfengine code
instead of being able to work within cfengine?  In my opinion, it's most
of the things I've already mentioned:  The limited module support (I'd
like to be able to configure modules within cfengin syntax, rather than
just inside an 'actionsequence' declaration), the inconsistent and limited
iterative capabilities (loops seem to be the main control structure
missing from the core cfengine syntax), the lack of a list and/or hash
datatype, and just generally how difficult it is to separate _what_ one is
doing from _how_ one does it.

I could go into more detail, but others have pointed out that it would be
better to have a "where are we going" discussion before we have a "how do
we get there" discussion.

Luke

-- 
I have an answering machine in my car.  It says, "I'm home now. But
leave a message and I'll call when I'm out."  -- Stephen Wright