>>> On 7/10/2007 at 7:29 PM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Brad: > > I got some questions regarding the python support module. > > Does it currently only support Python 2.4? Would it work with < 2.4 & >> 2.4? I am currently developing on CentOS 4 and it only comes with > 2.3.4. I do have Python 2.5.1 installed some place else so if there > is a way for me to specify the alternate location of Python libraries > that might help.
I don't think that there is anything in the code itself that requires python 2.4. The python module is fairly straight forward. Version 2.4 was just the version that we had to work with and I wasn't sure how to fix up configure so that it would allow multiple version. The spec file would also have to be fixed up to allow it as well. > > How does this implementation compare with Nick G's work? > > http://www.mail-archive.com/[email protected]/msg02865. > html > Giving his implementation a quick glance, the main difference is in-process vs out-of-process. Any implementation of gmetric still has to be scheduled outside of gmond which means that your metrics are being configured in two different places. That's not a bad thing because the advantage of gmetric is that you can easily add new metrics to a running gmond since it doesn't require any kind of configuration change. However you do have the overhead of being out-of-process. Both the DSO and python methods for building metric modules allow you to do some things that I believe, weren't really available before. Primarily the ability to create dynamic metrics that are based on hardware, service or application discovery. For example, the multicpu DSO module and the multidisk python module are both able to discover the number of cpus or disks on the box during init time and then represent each cpu or disk as an individual metric that can be included in a collection group just like any other metric. There is also no ramp up or tear down overhead because everything is run in-process. In addition, both the DSO and python modules can maintain state since they are never unloaded and reloaded. Bottomline is that it comes down to which method servers your particular needs better. I see advantages to both methods. > I am trying to build Ganglia SVN trunk under CentOS 4 to try out the > DSO stuff -- I got around the hurdles of apr-1 and libconfuse, but now > am somewhat stuck with the Python 2.4 requirement. BTW, is it > possible to build trunk using libconfuse from srclib/ (but libapr is > linked dynamically?) I'm sure that there is a way to do it, I'm just not an autotools guru so the problem is really how to fix up the configure script to allow you to specify where to build from. Since libconfuse doesn't ship on SuSE either, I made a few fixes to the libconfuse spec file which allows me to easily build a libconfuse RPM directly from the tarball. Once I build the RPM, the rest is actually simpler and the whole build process for ganglia goes a lot quicker. Brad ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
