Re: [Cfengine-develop] Development plan / meeting

[Luke A. Kanies]

On Mon, 3 Mar 2003 address@hidden wrote:

> Depends what you mean by monitoring. If you want a message on every run saying
>  "Yes DNS is still running..."
> You'll be insane within a few days. If you have 2000 hosts (as several 
> cfengine
> users do) you'll be insance within  a few minutes.

That's reporting, not monitoring.  I didn't even mention reporting, and I
would certainly expect that the reporting would be separate from the
monitoring.  No monitoring system should report success unless
specifically asked to do so; it should only report failure.  As such, I
would certainly never expect cfengine w/monitoring to report that DNS is
working, unless I specifically stated it shouldn't be working. :)

> > 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?
>
> CFengine has plenty of functionality for monitoring -- but what do you
> want to use it for? The idea behind cfengine is precisely to eliminate
> the administrator from as much as possible. Keep quiet, and keep things
> running..

Once again, this isn't about reporting, it's about monitoring.  I
mentioned a good example earlier:  Have cfservd report if a host which
normally reports every 30 minutes hasn't reported in X amount of time.
It's not that complicated of an operation, and would usually be
indication that either the host or cfengine on that host is broken.
There are many other simple examples, and again, like all good monitoring
systems, it would only notify of problems, not success.  And obviously,
you'd want some kind of hooks in there for non-email notifications; maybe
the ability to contact a central notification server or something, which
then decided on the notification method.

I actually think that functionality would be generically useful through
cfengine.  Email is an okay reporting mechanism, but at least most
enterprises have event collectors, and it'd be nice if cfengine had the
ability to dump its data into those collectors.

> > 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).
>
> But this is already what happens, so I don't understand what you are saying.

Kind of; cfengine already checks process tables, but it can't tell me if a
process is hung.  It also can't tell me if a host (other than a cfengine
server) is down.  It can't tell me if a higher-level remote service has
failed (for instance, if load directors have failed but the local
processes are all fine).  There are lots of things that could be checked.

> > computer do the most work, then the developer, and to have the
> > administrator do the least work.
>
> Exactly, so why do you want to bombard the poor sysadm with messages?

Please don't interpret monitoring as being equivalent with reporting.

> > 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.
>
> ok - there is always room for higher level stuff. Multilayered approaches
> are always superior to flat models.

Right, there's always room, but the fact that so many people are using it
means that for those people, cfengine qualifies as a tool, not a
framework.  Is the goal of cfengine to be a tool or a framework?  If
framework, what about cfengine's current state is forcing people to use it
as a tool, rather than a framework?  If tool, then it's essentially up to
you as the maintainer to decide what features you do or don't want.

To me, these two questions are the most important in this discussion, and
you are the one who most needs to put a word in.

> > 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.
>
> Yes, that is not incorrect. You are just asking for even higher level
> concepts.

Not really; you've already kind of got lists.  You've already kind of got
iteration.  You've already kind of got modules.  I'm just asking that all
of these be made explicit and much more usable.  If just those features
were added to cfengine, it would become infinitely more usable.  I, for
one, could likely begin using it as my main framework, rather than as a
tool.  As you mention below, these are not higher level concepts.

I think this discussion got sidetracked on the monitoring thing; if I had
better module support, it would be easy to add the kind of functionality I
want.  And even better, anyone could add it, and it could be shared.  I
envision plugins being distributed like perl modules, with a core
distribution and a CPAN-like repository with everything else.

> > What is it about cfengine that makes people have to generate cfengine code
> > instead of being able to work within cfengine?
>
> Now you've lost me again in rhetoric. How is coding in cfengine not working
> with it? You just want menus -- you're a closet windows user!!!

Um, no?  I'm sorry if this appears like rhetoric to you; I'm trying to
explain what I want out of cfengine, and provide examples as to why I
think others want the same.  I don't want menus, I want a real language,
with real datatypes and real control structures.  I want a generically
useful language which can stand on its own and not require higher-level
tools to make it usable.  I want to be able to do 98% of my work within
one framework, without having to constantly step outside that framework
for one reason or another.  I want the ability to easily add functionality
to my framework (in the form of modules, subroutine equivalents,
packages of functionality, etc.).

If these desires don't mesh with your goals, then that's fine; that's why
we're discussing it now.  I'm not even remotely interested in trying to
force you to make cfengine into something you don't want it to be; I've
explained what I want, now I just have to find out if cfengine will become
that language, or if I'll have to develop it myself.

And please leave the aspersions out of it; I'm trying my best to be
positive in this, and I'm trying to put the best light on what I want.
I'm especially trying to give you the respect you deserve for getting
cfengine to where it is.  But I'm obviously failing, if you think I'm
asking you to create a GUI for 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),
>
> I agree - but these are low level, not high level...:)

I don't think I ever asked for high-level functionality; most of what I
think is missing from cfengine is in the language itself, which is kind of
the definition of low-level.  Or another way of saying it, I can't add the
functionality I want in cfengine until these lower level capabilities are
added.

> Don't know what a hash datatype means - you mean associative arrays?
> All of these things require a modified language...long term goals

I guess only perl uses that term; yes, associative arrays.  Named so, I'm
sure you realize, because a hash function is used to associate their names
and values.  I use them probably 10:1 over arrays in perl, and would love
to have them in cfengine; they largely obviate the need for separate
namespaces.

Luke

-- 
Health is merely the slowest possible rate at which one can die.