Re: [Ganglia-developers] Auto configuration ideas
On Tue, Aug 26, 2008 at 11:06:03AM +0100, [EMAIL PROTECTED] wrote: From Tim's email: So, I could imagine gmond and gmetad staying the same and the above is one way for Carlo's greaper to work. There would be a new web service added to the gmetad server to manage site configuration. Since it knows all greapers that have requested configuration, it could notify them when their configuration has changed (all greapers could listen on a fixed port). They would then request the updated configuration and restart their gmond. What do people think about the extra complexity of gmetad initiating a connection to greaper? greaper doesn't exist yet (and might never do) but I think Tim's comments where about a greaper running in the gmetad server that will use gmetad's view of the cluster to figure out which nodes he has to contact and probably even managing gmetad as well (as is needed by his setup where nodes move around in between clusters) Obviously, at least one of the gmond nodes has to be accessible for gmetad to make a TCP connection and receive data. However, from the email sent the other day about UDP unicast, I'm guessing that there are some people who don't have two-way connectivity to all of their nodes. yes and neither can you assume that all gmond have two-way connectivity to all other gmond (even if it is collecting from them) Also, is there any reason not to have both the DSO module configuration scheme and the greaper scheme? no but I still think that the greaper approach is more flexible and was also hoping that it could be done in a modular way as you proposed while integrated with your solution. greaper could potentially use the same modules, it might work like this: - fetch `template' configuration file from gmetad or web server - parse the file with libConfuse - load the configuration modules - apply changes to the template configuration structure in libConfuse - write the file to disk again agree, eventhough it might probably make more sense to have all logic for deciding which configuration to use in the server than to be done on each node independently based on some template. 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Tue, Aug 12, 2008 at 02:14:15PM +0100, [EMAIL PROTECTED] wrote:
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
Here is my proposal:
- insert a dynamic_configuration step immediately after parsing the text
files and before any of the cfg_t structures are examined
how would this work for module configurations which could in theory also
include their own dynamic_configuration sections?
are all dynamic_configuration sections assumed to be global? how would you
deal with multiple entries? how would you handle configuration caching? how
do you handle other consumers of the configuration like gmetric?
- the dynamic_configuration() code loads a user specified module
to avoid confusion it will be better if those modules are not together with
the metric modules. using moduledir/conf/ instead of moduledir/ should be
enough to do that.
- the mechanism is purely optional and can be bypassed if the module
fails
Something like this is added to gmond.conf:
dynamic_configuration {
module_path = /tmp/mod_config_test.so
param = http://localhost/get_ganglia_opts.php?host=%s;
}
The module can use methods like cfg_setstr() to override the values
loaded from the configuration files.
still think that getting this into gmond is a stretch and even if the
implementation is done in gmond there is really no reason why this can't go
to a different configuration file.
===
--- include/ganglia.h (revision 1635)
+++ include/ganglia.h (working copy)
@@ -2,11 +2,14 @@
#define GANGLIA_H 1
#include rpc/rpc.h
+#include gm_mmn.h
#include gm_msg.h
#ifndef GM_PROTOCOL_GUARD
#include gm_protocol.h
#endif
+#include confuse.h
this changes our ABI and adds a external dependency to libConfuse which
I am not sure is warranted/desirable.
Index: gmond/gmond.c
===
--- gmond/gmond.c (revision 1635)
+++ gmond/gmond.c (working copy)
@@ -199,17 +199,34 @@
mmodule *metric_modules = NULL;
extern int daemon_proc; /* defined in error.c */
+void dynamic_configuration();
+
can't be this forward declaration be avoided?
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=100url=/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Tue, Aug 12, 2008 at 02:05:41PM +0100, [EMAIL PROTECTED] wrote:
I've been giving this some more thought. There are a
couple of issues
that come to mind:
- The default configuration might not always be appropriate - would
people welcome a patch that disables this behaviour (through a
configure option, such as --without-default-configuration)
no. if you don't want to use the default configuration all
you have to do is deploy your own.
That isn't always a safe assumption. Some people might prefer to have
the process fail, so that a process monitoring system tells them that
gmond is not running.
fair, how do you handle the use of the default configuration from gmetric?
I've prepared a patch for this, it must be explicitly selected at
configure time otherwise it has no effect on existing behaviour.
your patch got mangled by your MUA or MTA with line breaks inserted which
prevents it to be applied.
you might want to send it as an attachment (better if mime encoded as
text/plain) or check if you can avoid the line wrapping to break your patches
in the future.
Index: configure.in
===
--- configure.in(revision 1635)
+++ configure.in(working copy)
@@ -251,6 +256,10 @@
fi
fi
+if test $enable_default_config = no ; then
+ CFLAGS=$CFLAGS -DDISABLE_DEFAULT_CONFIG
+fi
you should use instead text x$var = xno;, is there a way to avoid using a
compile time define here and preprocessor magic, why not use config.h at
least?
if test $enable_python = yes ; then
echo
echo Checking for python
Index: gmond/gmond.c
===
--- gmond/gmond.c (revision 1635)
+++ gmond/gmond.c (working copy)
@@ -205,8 +205,16 @@
{
cfg_t *tmp;
+#ifndef DISABLE_DEFAULT_CONFIG
+ /* fallback to defaults if no filename given explicitly */
+ int fallback = !args_info.conf_given;
+#else
+ /* fallback to defaults prohibited in every case */
+ int fallback = -1;
+#endif
the same could be done by just defining (if disable_default_config is an
int that contains the value selected for how to handle the default_config)
int fallback = !disable_default_config !args_info.conf_given;
- config_file = (cfg_t*)Ganglia_gmond_config_create(
args_info.conf_arg, !args_info.conf_given );
+ config_file = (cfg_t*)Ganglia_gmond_config_create(
args_info.conf_arg, fallback );
why not remove the second parameter for that call and make the change of logic
in lib/libgmond.c instead?
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=100url=/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Mon, Aug 18, 2008 at 09:15:00AM +0100, [EMAIL PROTECTED] wrote:
Here is my proposal:
- insert a dynamic_configuration step immediately after parsing the
text files and before any of the cfg_t structures are examined
how would this work for module configurations which could in
theory also include their own dynamic_configuration sections?
are all dynamic_configuration sections assumed to be
global? how would you deal with multiple entries? how would
you handle configuration caching? how do you handle other
consumers of the configuration like gmetric?
dynamic_configuration { } appears once, although I could amend the patch
to have it appear multiple times or load multiple modules
what about being part of the module configuration and therefore loaded only in
the module scope for helping configuring an specific module?
Caching is currently dealt with inside the module (i.e. it is up to the
implementor to decide if they want caching, how long it is valid, how to
store it, etc)
because you are overloading the gmond configuration (gmond.conf) you are
preventing any implementor to just cache the configuration by writing a
gmond.conf. as I said before there is really no reason why the configuration
for this couldn't be in a different file and there are indeed several reasons
why it shouldn't be part of gmond.conf (and that includes of course any other
configuration included from it)
To support gmetric, we could probably break some of this off into
libganglia instead of gmond.
- the dynamic_configuration() code loads a user specified module
to avoid confusion it will be better if those modules are not
together with the metric modules. using moduledir/conf/
instead of moduledir/ should be enough to do that.
That is fair enough - maybe we should have:
moduledir/metric
moduledir/conf
maybe, specially once gmetad modules get deployed sometime in 3.2 but for now
moving your modules out of the way without disturbing anyone will be wise.
Or just name the modules by type, e.g. Asterisk uses names like
codec_XXX.so, chan_XXX.so, we could use names like cfg_XXX.so,
metric_XXX.so
no
- the mechanism is purely optional and can be bypassed if
the module
fails
Something like this is added to gmond.conf:
dynamic_configuration {
module_path = /tmp/mod_config_test.so
param = http://localhost/get_ganglia_opts.php?host=%s;
}
The module can use methods like cfg_setstr() to override the values
loaded from the configuration files.
still think that getting this into gmond is a stretch and
even if the implementation is done in gmond there is really
no reason why this can't go to a different configuration file.
It is optional - but for some people, like myself, it will be very
useful.
could you elaborate on which restriction on the amount of files in a
directory could explain this?
It doesn't have to go in gmond.conf - in my own tests, I've had it in a
separate file under /etc/ganglia/conf.d/cfg_dynamic.conf
and having it on /etc/ganglia/cfg_dynamic.conf and making gmond check for
that file existence first makes that much of a difference?
===
--- include/ganglia.h (revision 1635)
+++ include/ganglia.h (working copy)
@@ -2,11 +2,14 @@
#define GANGLIA_H 1
#include rpc/rpc.h
+#include gm_mmn.h
#include gm_msg.h
#ifndef GM_PROTOCOL_GUARD
#include gm_protocol.h
#endif
+#include confuse.h
this changes our ABI and adds a external dependency to
libConfuse which I am not sure is warranted/desirable.
ABI: it adds to the ABI, but doesn't change existing function
prototypes, so backwards compatibility is maintained
ok, but suspicious
libConfuse: it is already needed for the metric modules, as the
mmodule_struct contains a cfg_t pointer (gm_metric.h)
ganglia.h is NOT needed for the metric modules (gm_metric.h is).
ganglia.h is libganglia's public interface and does not require anyone
using libganglia to link with libConfuse (even if libganglia does).
if you are doing this to extend libganglia so that it can be used to
manipulate gmond's configuration then you will need most likely to make
an abstraction layer instead of just including libConfuse and calling
it.
I suspect though that since you are expected to do that from within a module
that is loaded inside gmond and you really need the ganglia module interface
(or your own extension of it for configuration modules) this is just a
mistake.
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=100url=/
Re: [Ganglia-developers] Auto configuration ideas
Reading through the backlog, what you guys really want is something similar to zeroconf/bonjour -- have any of you thought of integrating it with Ganglia? http://developer.apple.com/opensource/internet/bonjour.html This is cross-platform, works on Mac OSX, UNIX, Windows. How I envision it to work is that gmond will register itself in the registry and when other gmonds or a gmetad come up, they will automatically configure based on some internal identifiers. This should eliminate the need for configuration files (static or dynamic), DNS (forward and reverse), /etc/hosts file, etc. I was reading the internet draft about how it works through DNS and this does sound rather way cool. This appears to be more of a service discovery solution than a full configuration solution. Yes, I agree. Though there is a TXT area, it is only a few bytes and not designed to hold larger things like ganglia configs. There would still need to be a web service for handing out the configs, and I think this is all that would need to register. There are a few ways it could work: - gmetad could discover all the gmond nodes, and pick one at random for collection of data over TCP My gmetad wrapper adds up to 12 random hosts to the data_source lines to collect from multicasting clusters. More than that can segfault gmetad. And it can run a gmond listener for unicast clusters to report to. But I don't think it would be necessary for any gmonds to register... - the gmond nodes could discover a configuration server's name (regardless of whether it is HTTP, LDAP or something else) and then send a request to that server for a list of parameters (e.g. cluster name, multicast subnet, TTL) - this would be in one of my configuration modules Yes, only the gmetad configuration server would need to register. It will know the gmonds because they will all ask for a configuration to run through the web service. The web service then [re]starts any needed gmetads on the server, and sends the client the correct gmond config to run. However, I'm not sure that it solves the problem 100%. If I have 10 servers on the same subnet/switch, 4 servers belong in cluster A and 6 servers belong in cluster B, will Bonjour be able to tell each one the correct answer? I don't know, but the new ganglia web service could. The site-central server should know which cluster to put each host in, based on hostname, IP address and maybe netmask or subnet which the client would provide in the request. Maybe gmond should not know the cluster name at all - maybe gmetad should have an internal table of cluster names and nodes. Exactly. My clusters are already defined centrally, per site (domain), even outside the scope of ganglia. My automation just converts those known clusters into the correct ganglia configuration files. So, I could imagine gmond and gmetad staying the same and the above is one way for Carlo's greaper to work. There would be a new web service added to the gmetad server to manage site configuration. Since it knows all greapers that have requested configuration, it could notify them when their configuration has changed (all greapers could listen on a fixed port). They would then request the updated configuration and restart their gmond. Actually, this would even work without auto-discovery if the clients can be pointed to a static configuration server when they start up. This would work well where each domain has one ganglia gmetad server (which is how I do it). It would be more complicated if you are trying to spread the load over multiple gmetad servers in one domain as the clients would need to know which one to talk to. -twitham - 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Thu, Aug 14, 2008 at 08:45:47AM +0100, [EMAIL PROTECTED] wrote: Maybe gmond should not know the cluster name at all - maybe gmetad should have an internal table of cluster names and nodes. gmetad does have such a table in its configuration in the form of datasources which should include at least the cluster/grid name and at least 1 gmond which contains the information about that. fixing gmetad so that it overrides the cluster name using the name of the data source when it is not defined in the collector (as I explained before) would allow for something like what you were proposing here (except that you will still need to have a way to find all nodes for that cluster and instruct them to update the collector for that cluster). that last part works now by default if all servers are using the default configuration and the cluster is on its own VLAN, because they all will automatically collect and report the cluster configuration. 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
Guys: On Wed, Aug 13, 2008 at 4:13 AM, [EMAIL PROTECTED] wrote: Even if some of the configuration is dynamic, libConfuse provides a way to dump it's data structures to a string for convenient troubleshooting (see the cfg_print methods). I don't dispute the validatity of your solutions - I wish I could do something similar. However, look at it this way: I could spend a little time writing my auto-configuration in C and deploy it to every platform as part of the gmond package. Or, I can spend a my time getting approval to install some third party configuration tool (open source or otherwise) to every machine and every OS in the organisation. Imagine how many different stakeholders would need to be consulted to get Perl or Python onto every Windows machine. Which option will leave me with more time to work on things like new metrics? I see some really interesting discussions here, too bad I kind of joined late and had to catch up on all the emails. :-) Reading through the backlog, what you guys really want is something similar to zeroconf/bonjour -- have any of you thought of integrating it with Ganglia? http://developer.apple.com/opensource/internet/bonjour.html This is cross-platform, works on Mac OSX, UNIX, Windows. How I envision it to work is that gmond will register itself in the registry and when other gmonds or a gmetad come up, they will automatically configure based on some internal identifiers. This should eliminate the need for configuration files (static or dynamic), DNS (forward and reverse), /etc/hosts file, etc. If zeroconf works the way I expect it to, this should be a clean solution to Daniel's issue and would also serve as a pretty nifty contribution to Ganglia in terms of ease of deployment. Thoughts? Cheers, Bernard - 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
still, how does a restart happen or how is new configuration detected by gmond? There would still have to be something that pokes gmond to tell it to restart. And if that is the case, then we are back to why not just use an existing configuration management service. Exactly. Since the proposal does not provide for this, something external to gmond must still restart it to obtain a new configuration. That something may as well manage the configuration at the same time. This already works today. For me it is a perl program, for you it might be cfengine or puppet or manual update. The beauty of the current system is the simplicity and that you can just use whatever works for you. I like that I can look at the standard gmond.conf on any client and know the complete configuration, and this cached configuration works locally after reboot with no dependencies. It would be far more complicated if I had to go query a web service or LDAP server to see the configuration. I don't see much value in that. -twitham - 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
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.
Re: [Ganglia-developers] Auto configuration ideas
What happens when you have multiple clusters? Each node needs to know which cluster name and multicast address to use. In a huge organisation, it is not feasible for every node to join the same multicast group. In some clusters, not all nodes are on a shared multicast segment. So the default configuration is useful, but it is not a solution for everyone. Right, I can't use the default at all. My install is far too large and complicated to configure by hand. We have many clusters, and hosts move from one to another over their lifetime. I don't know if the options mentioned so far would work for me, but here is what I did. I wrote a perl script which allocates ports for new clusters and grids and auto-generates all gmond and gmetad config files on NFS. If a config file has not changed, then it is not re-written, so the timestamp on the files clearly shows the time of last change. Clients can all auto-mount this NFS config file area on demand. Shortly after the regular updates, they run a simple wrapper which looks on NFS to discover which config file they should be running. If this file is newer than their /etc/gmond.conf, then they copy it down and restart their local gmond. They do not restart if no change has occurred. Meanwhile, the server runs a similar wrapper around gmetad. Again, it restarts only the gmetad processes that have experienced a change in config file. The automation has also given them each a directory in the RRD tmpfs and a corresponding copy of the PHP in the htdocs area so they all have a working authority URL. I run several dozen gmetads on one host to implement our big tree of grids. The server can also automatically run mute gmond listeners for smaller unicasting clusters, though most are multicasting within subnets and then rolled up by a gmetad. The server also renames hostnames within the RRD area when they move from one cluster to another so that host history is preserved for all time through cluster moves. I could see a web service providing the config files instead of NFS; that could be more portable. In fact, it could be hosted on the ganglia server itself. The timestamp checks could still work the same. -twitham - 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Tue, Jul 29, 2008 at 09:51:58AM +0100, [EMAIL PROTECTED] wrote:
I've been looking at how we currently deploy Ganglia configuration files
in our organisation, and whether the process can be improved.
Is anyone already working on any aspect of this issue:
You should look at one of the existing configuration management tools
for this. Have a look at puppet/cfengine/bcfg2 and choose one that you
like. They will take care of pushing the configuration, restarting the
server and all other issues for you.
For my systems I am using puppet with something like:
$ cat ganglia.pp
define gmondconfig( $port, $cluster ) {
file { /etc/gmond.conf:
path = /etc/gmond.conf,
mode = 644,
owner = root,
group = root,
ensure = file,
notify = Service[gmond],
content = template(apps/ganglia/gmondconfig.erb)
}
service { gmond:
ensure = running,
enable = true,
hasstatus = true,
require = Package[ganglia-gmond]
}
package { ganglia-gmond:
ensure = present
}
}
The template is a standard config file with the cluster name and
send/receive ports as variables.
...
udp_recv_channel {
port = %= port %
...
Then for the different nodes I use definitions like the following
to add the machine to the right cluster...
gmondconfig { gmondconfig: port = 8690, cluster = foo.webservers }
gmondconfig { gmondconfig: port = 8691, cluster = foo.tests }
Cheers,
Kostas
-
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=100url=/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Tue, Jul 29, 2008 at 11:35, [EMAIL PROTECTED] wrote: -Original Message- From: Jesse Becker [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've been looking at how we currently deploy Ganglia configuration files in our organisation, and whether the process can be improved. snip - allowing a central configuration server to override some, but not all, of the values specified in the config file This is possible with cfengine, and other configuration management tools. I have several groups of machines, and There are some more details that were not in my original email: - it is a multi-platform deployment, including Linux, Solaris and an OS that requires Cygwin Cfengine works on all of those. Puppet works on the first two, and probably via Cygwin (Puppet is based on Ruby, and probably runs wherever Ruby does). - it is envisaged that some users will be able to change configuration settings through a web interface, and that those changes will be propogated to the nodes/clusters that the users who chosenfind It should be straightforward to convert webpage input into various rules files for cfengine/puppet/etc. These rules would then be used to push the various settings around as needed. -- Jesse Becker GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 - 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Auto configuration ideas
On Tue, Jul 29, 2008 at 09:51:58AM +0100, [EMAIL PROTECTED] wrote: I've been looking at how we currently deploy Ganglia configuration files in our organisation, and whether the process can be improved. gmond by design is able to work without a configuration for exactly this reason. the default TTL for multicast packets is 1 and the default multicast address should work independently on each VLAN as far as the clusters are segmented by network (a usual setup in HPC), and your switches are configured to handle multicast correctly and have no bugs. Is anyone already working on any aspect of this issue: as others had pointed, this is better handled by a configuration management utility, specially if you are stuck with that OS that needs cygwin and that wouldn't do multicast (from their release notes the beta version of cygwin 1.7 will be able to do multicast correctly in Vista/2008, but haven't really tested it) 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=100url=/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
