All,
The email discussion below prompted me to take a little closer look at the
configuration directives for the metric module interface. Currently there are
two types of module section directives. There is a "module" and a "pymodule".
The problem with this is that if or when another scripting interface module is
introduced, we will have to make modifications to libganglia in order to
support the new scripting language. In other words, we would have to add a
"perlmodule", "rubymodule", etc. to the valid configuration parser directives.
This is not the ideal situation. We should be able to introduce a new
scripting module interface by simply adding the module without having to change
anything in gmond or libganglia to support it. Since we haven't branched or
released anything yet, I am proposing that the following change be made:
1. Remove the "pymodule" configuration directive
2. Add an optional type name to a module section to designate the interface
type.
module { } - #No designation, the default is C
module Python {} - #Python type module interfaced through mod_python
module Perl {} - #Perl type module interfaced through (what could be)
mod_perl
etc....
By adding an optional interface type designation to the existing module
directive, we do not have to tie the gmond configuration parser to the
scripting language interface modules.
Just wanted to get any feedback on this while I rework the code.
Brad
>>> On 3/19/2008 at 12:39 PM, in message <[EMAIL PROTECTED]>, "Brad
Nicholes" <[EMAIL PROTECTED]> wrote:
>>>> On Wed, Mar 19, 2008 at 11:30 AM, in message <[EMAIL PROTECTED]>,
> Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
>> On Wed, Mar 19, 2008 at 09:11:28AM -0600, Brad Nicholes wrote:
>>> Carlo,
>>> Params is actually a valid configuration directive. There are two ways
>> to pass in parameters into a gmond module. One way is to use a raw string
>> with the Params directive (mod_python uses this for the module path string)
>> and the other way is to use the Param name/value block for individual
>> parameters. The documentation needs to be reverted to show the Params
>> directive.
>>
>> Params is a valid token for module, but it was used as a token for pymodule
>> here (where it is apparently invalid) resulting in :
>>
>> no such option 'params'
>> Parse error for '/etc/ganglia/gmond.conf'
>>
>> using libconfuse 2.5 as provided by the system and a modified example.pyconf
>> to match the instructions which I thought where probably outdated.
>>
>> # head /etc/ganglia/conf.d/example.pyconf
>> modules {
>> pymodule {
>> name = "example"
>> params = "Raw string parameter"
>> param RandomMax {
>> value = 600
>> }
>> param ConstantValue {
>> value = 112
>> }
>>
>> I agree it probably makes sense to be able to use 'params' in both cases but
>> if that should be working now then we have a bug to fix before reverting the
>> documentation.
>>
>> Carlo
>>
>> PS. the documentation for configuring python modules might make more sense
>> in
>> a README in python_modules IMHO, modules/python being a better place about
>> "python_module" and its configuration.
>
> I'll check this out. It should be available for both C modules as well as
> Python modules. I think I just need to fix the libconfuse parser.
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
