>>> On 10/17/2007 at 5:31 AM, in message <[EMAIL PROTECTED]>, Marcus Rueckert <[EMAIL PROTECTED]> wrote: > 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
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. 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. 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. Brad ------------------------------------------------------------------------- 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
