Re: [Cfengine-develop] Development plan / meeting

[Hugo Gayosso]

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

Andrew Stribblehill <address@hidden> writes:

> Exploring the workshop model: it'd be good to know roughly where
> developers live.

Michigan, USA.

> I'd like to extend cfenvd in some manner, to allow it to hear state
> information from other related hosts, and give a more configurable
> set of things it watches out for. For example, disk usage on more
> than just the root partition, user-defined port watching.

I also have some thoughts regarding either 'cfenvd' or a different
monitoring mechanism or both.

** Improve the monitoring capabilities

Expand the range of parameters that cfenvd monitors, and an easy way
to configure/enable/disable the monitoring of each parameter.

Or, by creating a set of "plug-ins" that are run by 'cfagent' or
'cfexecd' (e.g. check_memory, check_swap, etc.).

In other words I would like to get rid of the need for a central
monitoring software (e.g. Netsaint, now Nagios) to check the status of
some services/hosts.

This has other consequences like the need of a way to find out if all
of the machines in a certain group are alive, by removing the
centralized monitoring system, you need a method by which the machines
check if their peers are alive and if cfengine is working.  Now if one
my machines dies or loses connectivity, Netsaint sends me an email,
how would I do this if I only ran 'cfengine'?, I have thought of
something but I haven't implemented it.

*** Are you ok? (heartbeat)

In order to solve the problem I described above I thought that the
machines could ask each other "are you ok?" maybe partition the entire
group of machines into subgroups, and use an algorithm so we don't
create a storm of "are you ok?" queries all over the network, only the
minimal that is needed to find out if EVERY machine is up and ok, that
if developed well, that algorithm could reduce the amount of network
traffic compared to the traffic generated by having a single central
monitoring system.


> > Anything else is open to discussion.
> 
> In the past few weeks, when users have said, "Can I do this", I've
> replied, "No but here's a patch to let you do it." I'm not sure this
> is the best way to manage the inclusion of features. How do we want
> to do it without formalising the process too much?

Maybe setting up a RFC (Request for Comments) where the developer
donating the feature sends an email describing it (with code if
possible) and then if there are no opposing comments go ahead and
implement it in the development branch, which still could be rejected
before releasing by Mark.

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

iD8DBQE+YNi/MNObVRBZveYRAoMcAJ4//hDF45VvU8YbzJ8uAuXOTs20zgCeM0ku
KuaSoZKwnlkm4xatCUPEXJ0=
=rEcH
-----END PGP SIGNATURE-----