>>> On 11/26/2008 at 1:17 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 04:33:05PM -0700, Brad Nicholes wrote: >> >> The result was that if the wildcard produced more than 10 included files >> (which it easily does even in our default configuration), libconfuse >> choked because it thought it had hit the maximum nesting level > > our RPMs for ganglia only install 3 files in /etc/ganglia/conf.d; gentoo > has 2 and fedora 10 (just released) has 4. > > even if I agree that 10 is somehow low and you would expect that as more > modules are deployed it will be soon problematic, it would seem that at > least in this case, one problem was traded for another. >
The fact is that 10 is low which is why I discovered that last year when I implemented the wildcard path support. In our case we routinely run with 20+ modules and configure them using separately included .conf files so that each one can be easily turned on or off by simply renaming the included .conf file. This is a very valuable feature which isn't unique to ganglia. Limiting this very useful feature now in gmond on the remote chance that a file system might go read only and cause an issue for gmetric, isn't a very good trade off. It isn't that one problem was traded for another. At the time when I implemented the code to support wildcard paths, nobody knew anything about gmetric not being able to run in a read only file system. There was no trade off begin made. The fact is that whether or not gmetric is able to run in a read only file system is a much smaller issue than allowing gmond or gmetric to run in an undetermined state because the code allows parts of the configuration to be ignored. Introducing a patch that knowingly ignores parts of the configuration due to errors in the file system is unacceptable behavior. The bug that this kind of patch introduces is much larger than an issue with gmetric not being able to run in a read only environment. Gmond being able to resolve wildcard paths is a standard feature and behavior that is used every day, gmetric being able to run in a read only file system is not. The real issue is why did the disk go read only. There are plenty of gmond metrics that provide the administrator with warnings and a metric module that indicates when a file system has gone read only is extremely easy to write. A more acceptable solution to the gmetric problem is to provide gmetric with its own .conf file that contains just the socket and port information rather than pointing gmetric at gmond.conf. In this case both gmond and gmetric will continue to run even in a read only file system. This solution can be easily implemented today without any code changes and especially without a code patch that introduces a much more serious bug. If we need to solve the gmetric being able to run in a read only file system, then we need to come up with a better patch. Crippling gmond and gmetric with a patch that allows them to ignore a fatal error because parts of the configuration was skipped, is not an acceptable patch. 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-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
