>>> On 8/30/2008 at 12:42 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Sat, Aug 30, 2008 at 01:52:03AM +0100, Kostas Georgiou wrote: >> >> Another option will be to have each module able to print some usable >> configuration. I am attaching some patch from a quick hack that I wrote >> for the multidisk plugin to output a usable .conf file. Maybe extending >> the mudule api with a metric_autoconf function so you can do a gmond -t >> modulename > modulename.conf (or something similar) is a good idea. > > I know I am usually the guy turning people down and bitching for no apparent > reason and I had been trying to force myself not to say anything about this > patch so just I can't keep with tradition but this is just pure genius. > > So here I go; this is BRILLIANT and if it wouldn't be for the fact that you > mention is a quick hack (which usually means is just code that should be > thrown away) I would had this committed already in trunk and working on > getting the same done for all remaining modules (python and otherwise) > > Adding some sort of introspection to the modular metrics to allow for this > (just like gmond does itself) is IMHO the best way to go and fits perfectly > with the ganglia model used so far of selfcontainedness. > > But of course as you mentioned will need some sort of framework designed > around it which most likely won't be ABI compatible with the current modular > implementation, but that shouldn't be that big of an issue as there is > already > support for versioning in that framework in preparation for this day. >
Actually I think we can do this without affecting ABI (See my other post). I haven't thought it through completely (and I really don't have the time to think it through at the moment), but I think that the metadata framework that already exists in the module interface, should be able to handle this quite nicely. It could be added in exactly the same way that GROUPS where added to the module interface. For those interested in pursuing this further (since I don't have the time right now), for the C interface which would have to be handled first, just add a new tag to the header file called AUTOCONF (or something like that), then within the module code use the existing macro MMETRIC_ADD_METADATA() to add the autoconf information. That should allow the module to supply gmond with all of the information it needs. From that point it should just be a matter of adding some new functionality to gmond to allow it to autogenerate a configuration file for a module or an entire configuration file using the -t option. I'm sure there are some "gotchas" to this, but hopefully it will point somebody in the right direction. Another option which would affect ABI and would probably have to wait for 3.2.0, would be to add an additional field to the mmodule structure. This would actually be the cleanest way to add the functionality, but would have to wait for 3.2.0 which might be a while. Brad Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
