steve- you can see that the only metadata i've put in right now is plugin name, author and version (see test-plugin.c ganglia_main()). i welcome any ideas of more metadata that we need.
right now, i envision that we will have a service plugin directory (say /var/lib/ganglia/services). every file in that directory will be loaded at gmond (gserviced?) startup. each of the service plugins will then load up all the data collect/publish plugins that it needs. keep in mind that a collect/publish module is not restricted on the number of metrics it can process. i just uploaded another snapshot of g3 to http://matt-massie.com/g3/ you can see how i changed the job scheduler. each job has a job-specific collect and publish function now (see g3_job_t in g3.h). i needed to have both functions in each job (instead of linking them) in order for us to have multiple service frontends. here is the tree - service +- priority queue (heap) +- load/ cpu plugin +- memory plugin +- any number of plugins the frontends will plug directly into the heaps. the beauty of it is that the underlying heap is just a simple C array... each position in the array is a job/plugin. developers (us) can then build any number of presentation methods for the data (xml, ldap, sql, s expressions, whatever) inside a single service. this also allows us to have push AND pull methods for publishing metrics. you'll see inetaddr.c tcp.c udp.c and mcast.c in the distribution now. g3 will have a full multicast, udp and tcp library to use in building these services. i've compiled and tested the networking library on Linux, Solaris, FreeBSD, Cygwin and MacOS X. .. i got off track there .. back to the plugin question... if a plugin is compiled on a different platform than the one trying to load it then dlopen() will fail and we won't even be able to get at the meta-data. i think the question you are hitting on is this.. what is the best approach to building the plugins: platform-specific or metric-specific? platform-specific means that a developer builds a plugin which only works on a single target platform but has many metrics (this is more like our approach in the past).. OR.. should have a a metric-specific plugin (say load) which only measures a single metric but works across a range of platforms. i think the first approach is best... .. .. you know.. i just realized that i'm rambling on and on.. if you find anything useful in this message.. please feel free to reply.. -matt Yesterday, Steven Wagner wrote forth saying... > So while I'm tooling around CVS, I'm reading Matt's latest g3 examples and > I start to think about plugins. > > How is this going to work? > > Will we have a baseline plugin for each platform (irix_baseline, > solaris_baseline), or will that be compiled-in in some form? > > A version/compiled-on timestamp? > > Will there be a facility to mark a plugin as platform-specific? Not so > much to prevent people from porting it, but just something there to prevent > Ganglia from barfing on an attempt to load a downloaded precompiled binary > for the wrong platform... ("It won't happen," you say. "640kB is enough > for anybody," I say, AND LAUGH!) > > As soon as part of the API stops glowing a dull red (at least as far as the > basic scheduling methods are concerned), I might give one or two "plug-ins" > a shot... > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Ganglia-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ganglia-developers >
