Hi Brad, ----- Original Message ---- > From: Brad Nicholes <[EMAIL PROTECTED]> > To: Marcus Rueckert <[EMAIL PROTECTED]> > Cc: Ganglia Developers <ganglia-developers@lists.sourceforge.net>; Alex > <[EMAIL PROTECTED]> > Sent: Wednesday, October 17, 2007 5:52:57 PM > Subject: Re: [Ganglia-developers] Ganglia spec file cleanup > > >>> On 10/17/2007 at 5:31 AM, in > message > <[EMAIL PROTECTED]>, Marcus > Rueckert wrote: > > On 2007-10-16 17:06:47 -0600, Brad Nicholes wrote: > >> >>> On 10/11/2007 at 4:11 PM, in message > >> > , > "Bernard Li" > >> wrote: > >> > Hi Alex: > >> > > >> > On 10/11/07, Alex 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 > > > Actually the scenario that I am proposing would eliminate all of > the > built in hardcoded metrics and move them out of gmond as python > modules.
I definitely agree that the notion of "core metrics" should go in 3.1. At least they should no longer be hardcoded, but loadable. What I do not agree (and you probably didn't mean it that way) is to replace everything by Python code. C Modules should still be allowed and be first class citizens :-) > This would allow gmond to be just the collection and transport > daemon > as it should be. Then the user would have full control over > which > metrics they want to allow in their system, which version of a metric > they > want to use, allow them the ability to easily tweak a metric for > their > particular platform if necessary without having to get into the > guts > of gmond to do it. Absolutely. > It would also eliminate the need for the > PHP > interface to have to know about gmond vs gmetric metrics. Everything > would > just be a metric. So in this case, unless your system is running pure > C > interface metric modules, python would be a required component. > Nothing against making Python required, but as I said I strongly oppose making C (or other language) modules second class. Cheers Martin ------------------------------------------------------------------------- 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
