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=100&url=/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
