Re: [Cfengine-develop] Development plan / meeting

[Hugo Gayosso]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Burgess <address@hidden> writes:

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

As Luke said, one thing is monitoring and another is reporting.

Anyway, I don't want gratuitous anything, whatever is monitored should
be because it matters to the status of the system and preferably
should have some rules to fix it if it breaks, I prefer the system to
take care of the problem than the system whining for my help.

Real life example: one my systems gets "/var" full and the reason I
have detected is because one daemon gets crazy and starts to grow its
log files so, now instead of having cfengine tell me that "/var" is
full, it goes and restarts the daemon and purge the spurious log
files, I don't even know.

So in this case there is monitoring (disk space) but there is no
reporting.

> Luke, I don't understand you. In what way is cfengine NOT a
> framework?  What do you think is missing?

In short, I think that whatever other people is doing to "complement"
cfengine or as a "hack" to cfengine could tell us what is missing.
Some things as you said are because people is "not thinking straight"
but let's not forget that sometimes it is because people is not used
to the "cfengine way", so maybe one of the big things that is missing
is a different way to document how to use cfengine.

The tutorial, reference and the other documents in the website are
great, but some people might not understand or might not be able to
see "the big picture" so providing them with a library of recipes
might be better for them.

- -- 
Hugo Gayosso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+ZB4fMNObVRBZveYRAlgaAJ4trJBCzkSgsDHBGCgVDij27l/pGgCghbxo
YhrRtXtSrPyX/w/mnCOlWKc=
=tOU4
-----END PGP SIGNATURE-----