On Mon, Aug 11, 2008 at 08:53:58AM +0100, [EMAIL PROTECTED] wrote:
> > > Fetching the configuration file from a web server is quite a valid
> > > solution - and as you point out, the file can be cached
> > locally. In
> > > contrast, the benefit of LDAP is that it can enforce some
> > structure,
> > > it can integrate with an existing LDAP deployment, and it can be
> > > examined using a range of query tools.
> >
> > if you really feel so strongly about LDAP (which means you
> > had never seen how ugly that can get) then knock yourself out
> > and do it, just please keep open the possibility for using
> > some other mechanism (like http).
>
> When I raise an issue like this, it is often because I am considering
> implementing it myself.
I wasn't implying I would do it, because I won't (specially if it is based
on LDAP) and definitely I was expecting you to provide the code once the
implementation details were ironed out (which you removed from this post)
As I said before (an others as well) I don't think is a good idea because
ganglia is NOT a configuration management tool and there are plenty of them
to chose from that could be used to solve this problem far better than any
ganglia specific solution could. You have your reasons to disagree and that
is OK, after all this is opensource and we all don't have the same problems
to solve in our environments.
Talk is cheap though, which is why I was suggesting instead we let code do
the talk ;)
> The reason for the discussion is that I'd like
> to have some agreement about the concept before I just say `like it or
> not, here is a patch, this is the way I wanted to do it'. I didn't put
> this topic on the list in the hope that someone else would just do it
> for me.
fair, and so for the sake of clarity let me explain again what are the
specification constrains :
* must allow for nodes to specify where the configuration server is
* must allow for additional configurations to be included for modules
* must allow for configuration updates
* should allow for nodes to be notified when configuration changes
require them to be reloaded
* should allow caching the configuration locally
* should fallback gracefully in case configuration server is not available
* should provide other applications (like gmetric) configuration services
> Let's ignore LDAP, and just assume there is a generic configuration
> server (LDAP, HTTP, NFS). The existing code can probably be generalised
> a little more to support this and allow the deployer to choose between
> those options or implement their own. How would this mechanism behave?
> Would there be some interaction between the text files and the server,
> or would they be mutually exclusive?
currently the default configuration (inside gmond) and the configuration file
are mutually exclusive as there is no merging/overriding between them.
> Here are some issues:
>
> - Module configuration should probably be file based - that way,
> installing or removing a binary package (.deb, .rpm, etc) containing
> modules can update the file on disk. I already do this with my custom
> modules, the RPM and Solaris packages insert a file in
> /etc/ganglia/conf.d with a modules{} section describing my in-house
> modules.
that is how is done now (the default configuration imports all configuration
files in that directory and segfaults gmond but that is a bug).
there is really no reason why the module configuration couldn't be pulled
as well from the configuration server though and you could as well do merging
for those pieces.
> - Config server details (protocol, hostname) have to be stored on a
> local disk, unless they are compiled in - this requires a new section in
> the config
as I suggested before will be better if a new configuration, this way the
configuration parser would be simpler and you won't have to also solve the
fact that there is currently no way to override only some configuration
parameters using the local file configuration.
now you either have a configuration file for gmond and use it, or you don't
and use the default.
> - Some other parameters, e.g. the user ID to use, are needed before
> contacting the config server and will have to be in a local file
not sure why.
> - Other globals can probably be defined locally and the config server
> can override them
OK, not a "must" but a nice feature to have. as I explained before though
it could get very interesting if you are also going to handle override rules
between local configuration and the default.
same will be needed for the "cluster" and "host" sections most likely.
> - Details of UDP and TCP sockets, and collection groups, can probably be
> merged - read them first from /etc, then read cluster-wide settings from
> the server, finally read the host-specific settings from the config
> server
OK, same problem that with the previous point.
> - Re-configuration can be server specific - it will be up to the
> implementation. It may be as simple as the config implementation code
> sending a HUP signal to itself.
not sure what you mean by "server specific" but at least currently a SIGHUP
signal will just kill gmond, the only way to get gmond to reconfigure itself
is to restart it, which is why I mentioned before it would make also more
sense to implement this outside of gmond (even if you want to do this
configuration management ganglia specific).
an implementation could be done by adding a program that runs as root
(maybe even in a scripting language like python) that will do:
* read the configuration to locate a configuration server
* pull the configuration from there and generate a local gmond.conf
* start gmond with that configuration
* restart gmond whenever notified that the configuration has changed
if you want to do it inside gmond for whatever reason, then you will need
to add and extra fork while daemonizing and do the work in the parent, but as
Timothy explained it could be as well done with some scripts and crontabs
Carlo
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
