>>> On 7/1/2008 at 2:40 AM, in message <[EMAIL PROTECTED] , <[EMAIL PROTECTED]> wrote:
> > > Hi, > > Just a few questions about the multi-disk module implemented in Python: > > http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/gmo > nd/python_modules/disk/multidisk.py?revision=846&view=markup > > - The code seems to be intended for Linux - what is the intended > strategy for handling multiple architectures (e.g. Linux and Solaris)? Currently, there really isn't any kind of strategy. > Should a single module handle all architectures, or should there be a > different module for each architecture? Also, does gmond have some way Ideally a single module should be able to handle all architectures. Practically, this may not be possible with some metrics. My guess is that for some modules like multi-disk, there will probably have to be different modules for each architecture or at least for architectures that are different enough to make it impractical for a single implementation. > of recognising whether a specific Python module is suitable for the > current platform? > No, not in the current implementation. Of course this kind of functionality could be added later to the module interface. > - How should such a module handle disks that are not always present, > e.g. iSCSI SAN volumes attached after the process has started? Is it > appropriate to re-initialise the list of metrics while gmond is running, > or is it necessary to restart the entire gmond process each time disks > (or NICs) are attached/detached? > In the current implementation, gmond will have to be restarted in order to recognize new disks. I have looked into a way for the metrics list to be reinitialized on the fly, but haven't been able to come up with a good implementation. Part of the problem is that any new metric also requires a configuration file change. There would have to be some way for either a module or a user to poke gmond and tell it to re-read the configuration file and then reconstruct the metrics list without dropping any of the in memory data. I am guessing that a robust implementation will probably also include some way of generalizing the Collection_Group configuration section so that each metric does not have to be listed individually. The set of enabled metrics would somehow have to be generated on the fly. Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
