On 2007-10-16 17:06:47 -0600, Brad Nicholes wrote:
> >>> On 10/11/2007 at 4:11 PM, in message
> <[EMAIL PROTECTED]>, "Bernard Li"
> <[EMAIL PROTECTED]> wrote:
> > Hi Alex:
> > 
> > On 10/11/07, Alex <[EMAIL PROTECTED]> wrote:
> > 
> >> > - new subpackage modules-python which contains all the DSO/python
> >> > modules (not really happy with the naming, so suggestions welcome!)
> >> >
> >> How about extensions-python?
> > 
> > Actually I guess I also have concerns about the division of the files,
> > since gmond contains the C modules and the modules-python contains
> > just the python modules -- I wonder if this division is necessary.  I
> > guess I'll wait for some feedback from Brad since he's the one who
> > came up with the code.
> > 
> 
> I would rather have all of the metric modules (both C and python)
> installed with the gmond package.  But not all of them have to be
> enabled. 

but that would still require to install python although i might not even
use it. for the moment i would propose using a subpackage for it.

> My vision moving forward (just my 2 cents) would be that the
> ganglia community embrace the python interface as the preferred way to
> extend gmond with new metric types.  To promote this, installing and
> configuring mod_python by default would encourage the use of the
> python interface.  I've mentioned this idea before on this list, I
> would also like to see a python metric module repository as part of
> the ganglia project that would allow the ganglia community to upload
> and share metric modules similar to the gmetric repository.  

if an use wants a python based metric type he can easily install the
package.

> In our own internal RPM builds, we have been installing disabled
> python modules to an "extra" directory.  In other words, a disabled
> python module .pyconf file would be installed to
> /etc/ganglia/conf.d/extra and the corresponding .py module file would
> be installed to /usr/lib/ganglia/python_modules/extra.  This allows
> the user to simply move the .pyconf from extra to conf.d and the .py
> module from extra to python_modules.  Then restart gmond and new
> metrics appear.  Another option would be to install the .pyconf as
> .pyconf.off and the .py to the python_modules directory.  With the
> config file named .pyconf.off, the gmond configuration file parser
> will ignore it during startup.  The downside of this is that the .py
> module will always be loaded just because it exists in the
> python_modules directory, even if it isn't being used or referenced by
> a configuration file.  Of course without a corresponding
> configuration, even if the .py module is loaded, it's metrics won't be
> produced or appear in the -m metric list.  

you can/should do that even with the python module splitted out. as the
user might not want all python metrics enabled.

> Now after having said all of that, there is an option that could be
> adopted later.  If myself or anybody else enabled gmond with other
> scripting language modules such as perl, PHP, TCL, etc., then it might
> make more sense to split the different enabling modules with their
> associated metric plugins, into separate RPM packages.  But for now,
> including the python enabling module along with the python metric
> modules with gmond, seems more convenient.

from a packager/dependency point of view it makes sense to split it out
to give the user the choice if they want python or not.

    darix

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to