cfengine-develop
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfengine-develop] Development plan / meeting


From: Mark . Burgess
Subject: Re: [Cfengine-develop] Development plan / meeting
Date: Mon, 3 Mar 2003 17:31:19 +0100 (MET)

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

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

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

> 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?

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

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

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

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

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

M

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






reply via email to

[Prev in Thread] Current Thread [Next in Thread]