On Thu, Nov 06, 2008 at 10:26:42AM -0700, Brad Nicholes wrote: > >>> On 11/6/2008 at 5:07 AM, in message <[EMAIL PROTECTED]>, Carlo > Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 06:13:47PM -0700, Brad Nicholes wrote: > >> Carlo, > >> In the STATUS file you commented that the spoofing patch needs more > > work. > > > > my comment was about the spoofing "feature" needing more work in 3.1 as you > > pointed out below. > > > > the patch just makes the problem bigger by adding several changes (more than > > 500 lines) on top of an implementation that has open regressions and that > > will need to be cleaned up first IMHO. > > You really have me confused here. What problem are you talking about > that the spoofing patch makes worse?
Simple math; current implementation for spoofing in 3.1 has problems and 1 user (gmetric), by adding the patch the problems it has will need to be fixed for 3 users (gmetric, modpython and libgmond) and will have 500 additional lines of implementation to fix. > >> I have committed a spoofing example python module in trunk that spoofs > >> cpu_util, boottime, heartbeat and osname for three imaginary machines. > >> This spoof example module runs under both trunk and the patched 3.1.x. > > > > Sadly I haven't been able to make it work, with `gmond -m` showing : > > > > # gmond -m > > (module python_module) > > load_one One minute load average (module load_module) > > ... > > I'm not sure what you are talking about here. because of the showstopper bug detailed below, there was no way to test the python spoofing support in my setup. I got x86 linux (Fedora 10 alpha) installed and used that instead. > > and python modules in general not working anymore (linked against amd64's > > python 2.5.2 in Linux) > > What doesn't work? Also, whether or not the python modules are not working > in a specific environment is a separate issue from the modular spoofing > proposal. OK > This issue should be dealt with as a separate bug and backport proposal > if required. filed as a showstopper for 3.1.2 in the STATUS file instead. patches to fix it are already queued and voted so it will be solved as soon as all relevant patches are backported. > > the "C" interface seems to work fine at least in 3.1 (in trunk it messes > > GMOND_STARTED as explained before) > > I responded to this issue in a separate thread. do you have a link to that thread?, I might somehow dropped of it then. > That meant that gmond was getting multiple heartbeat packets for the > same host which caused the GMOND_STARTED value to flip-flop betweeni > the various heartbeat values. GMOND_STARTED should never change because of a spoofing packet (unless that is what is being spoofed and that could be only done through the spoofing support in the modular metrics which is being discussed), LAST_REPORTED is the only metric that should change with a heartbeat. in any case, this problem was only reproducible in trunk AFAIK, so is hopefully not relevant for this review but still a bug that needs to be tracked and fixed. > Also if you had used gmetric to send a non-spoofed heartbeat, this will > cause the GMOND_STARTED value to update. The reason why is because > the gmetric heartbeat for your host will override the gmond heartbeat > until the next time that gmond sends it's own heartbeat for the same host. this seems to be another bug to track and fix. > >> I have also created a patch for sending a heartbeat through the shortened > >> commandline which has been proposed as a follow-on backport. > > > > saw that, not sure about the needed dependency in the modular spoofing > > support as IMHO a change to gmetric should be independent of that. > > It is, but due to the fact that the shortened commandline patch was > introduced in trunk after the modular spoofing, it just created an > ordering dependancy. Again, this is only due to the way that we develop > in trunk. As I mentioned before, I chose to treat it as a separate patch > because they are really separate issues and there is no need to make > the modular spoofing patch more complicated than it needs to be for review. > If I could break the modular spoofing patch down into multiple functional > patches, I would do that also so that patch reviews would be easier. > Unfortunately, I can't. OK, since this is a regression from 3.1.0 and not that difficult to review would be probably a good idea to get it backported for 3.1.2 as well. Carlo ------------------------------------------------------------------------- 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
