Re: [Ganglia-developers] PATCH : Adding trends to Ganglia
On Mon, Jan 4, 2010 at 10:03 AM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: On Tue, Dec 29, 2009 at 02:49:28PM +0100, Sebastien Termeau wrote: OK, I will provide you with two new patches that include those remarks. BUG249 (the one about using tables for formatting of the host view) is IMHO already closed, and unless you really meant to (as I expected and asked before but got no confirmation) to be really an enhancement that would be released with some 3.1 version (most likely 3.1.7). if that is the case, please update the target on the bugs or if you can't do that let me know and I would do so and track the corresponding backport for the release. I agree. How do I change the target version? It is the version number in the bug description? BUG250 will need an updated patch that can be applied cleanly to trunk so that it can be tested/enhanced further. I just submitted a new version of the patch. This one can be cleanly applied to trunk. I slightly modified the order in which thinks are done in graph.php in order to calculate the 'start' and 'end' values before calling the metric.php script. I was also thinking of adding a third one with minimum, maximum and average. Do you think it might be interesting to have this graph also? AFAIK, those values are already in the metric graphs as numeric values, and the MAX is also graphed with a red line, is that what you were looking to add? Yes it is. I was thinking that maybe the normal graphs should not come with this max line. And instead, we can provide a new 'trend graph' with MIN, MAX and AVG drawn as lines. Regards Sebastien -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] template-based metric definition with PCRE
Carlo Marcelo Arenas Belon wrote:
On Mon, Dec 28, 2009 at 08:47:35PM +, Daniel Pocock wrote:
Jesse Becker wrote:
On Sat, Nov 28, 2009 at 08:42, Daniel Pocock dan...@pocock.com.au wrote:
For those following trunk, you may need to bootstrap again, and make
sure you have pcre available.
I've linked gmond with libpcre so that it can dynamically match the
metric names
E.g., for the multicpu module, this is the only metric definition that
needs to be given to enable all metrics on all cores:
metric {
name_match = multicpu_([a-z]+)([0-9]+)
value_threshold = 1.0
title = CPU-\\2 \\1
}
Oh, that's cool. +1 for me.
I've backported to 3.1,
that was a bad idea IMHO, not because the implementation is bad, but because
3.1.3^H4^H5^H6 has been delayed long enough that adding anything else to it
this late and therefore resetting the testing cycle would be unwise;
specially considering there are other fairly significant fixes/features
waiting as well for backport as well.
That is a risk - that is why I have now made it completely optional
there is also the fact that there was a valid (sorta, even if no code was
ever produced otherwise) comment on how this functionality should be made
optional (just like python is) and that wasn't discussed further (except
on this email after it was committed), neither corrected.
Now this has been done - I've also demonstrated how to do this with a
single configure option, we should consider the same syntax for the
python option
lastly, this code makes using multicpu so easy that it will be fairly obvious
the module never worked fine to begin with and so it would therefore make
more sense to also backport the needed fixes in r2116 (still incomplete), and
maybe even the configuration cleanup patches in r2118 which are also somehow
related, and also consider better ways to protect users of other platforms
than Linux and Cygwin from shooting themselves on the foot by trying to get
that module loaded, and which is an even bigger issue.
Is it the job of the release manager to apply each backport himself, or
can these tasks be assigned to the people who developed the patches?
I think that exposing the problems in multicpu is not such a bad thing -
hopefully it will encourage people to contribute fixes.
$ svn log -r2160
r2160 | d_pocock | 2009-12-28 20:43:54 + (Mon, 28 Dec 2009) | 1 line
Patch for PCRE support (backport r2112 and r2119)
you are missing also r2150 and r2156 and some yet not existent patches
so that the dependency will be also in the RPM SPEC and documented in
the configuration man page and other needed places.
Those changes have been backported
The RPM spec and man page have been updated now
I've also updated the STATUS file
would suggest instead to revert this backport for now.
With the change I have made, do you still believe we should revert this?
I'd be interested in any feedback on the PCRE dependency. If necessary,
the feature can be made into a compile time option so that gmond can
build without it.
Yes, an optional compile time option is the way to do this. Use it if
present, but continue on without it if not present.
Is PCRE not available on any platform that we want to support for 3.1?
most likely available everywhere (just like python), but since not having
it would most likely only imply that the use of the corresponding
configuration wouldn't be possible it really makes sense to be considered
optional.
If not, then I'll leave the patch as it is, too many #ifdefs can make
the code look messy. The current implementation tries default locations
for pcre, or let's you specify your own version:
./configure --with-libpcre=/opt/pcre
ideally all that should be needed will be to also have a --enable-pcre or
equivalent flag to control how to disable support for this at compile time
just like it is possible for python (and that has proven to be really useful
for Solaris users AFAIK)
To disable it:
./configure --without-libpcre
or
./configure --with-libpcre=no
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Wed, Nov 25, 2009 at 11:00:21AM +, Daniel Pocock wrote: b) should the choice of bootstrap environment be locked for all 3.1.X, and only changed when increasing the minor version number (e.g. when we go from 3.1 to 3.2)? no, but since our build system is full of hacks and not completely reliable it might be a good idea to test no issues are introduced when looking at a new version. Ok, but if it is not locked down, let's consider some of the following: - document the version we expect agree, and that is what README.SVN is for, but first we have to decide which version to expect to begin with. - maybe add some check to configure that warns if a different version of autotools is detected? configure doesn't depend autotools and so that would be the wrong place to put any checks, but configure.in does and there is where bootstrapping should be aborted using AC_PREREQ and friends if using the wrong versions. Ok, should we use AC_PREREQ for 3.1.6, are there any disadvantages? only if the macros will definitely break with an older version of autoconf as otherwise all we are doing is enforcing a recommendation and preventing anyone that might not have access to the newest version of autotools the posibility of getting their own bootstrap (not much of an issue if we also provide regular snapshots though). I've had a quick search for information on this - it appears that adding AC_PREREQ(2.61) would cause bootstrapping to fail on any older or newer version - only 2.61 would be supported. I think this is the right way to go, as it will prevent us from running in to the same issues again, and it will hopefully prevent people building trunk with a different version of autotools and creating bugs that no one else can re-produce. d) Can anyone volunteer to provide a stable bootstrap environment (e.g. a virtual server) just for Ganglia? Two such environments may be needed, one for trunk and one for the current release branch. Matt did offer an EC2 instance if we could agree on an OS version : http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg05271.html I suggested Debian 5.0 (more conservative) or Fedora 12 (to be updated more frequently) but as far as it is agreed, documented and reproducible anything should work. I prefer Debian 5.0 (lenny), that is what I have on my laptop, home PC and various other infrastructure that I use. Elsewhere I am using RHEL3/4/5. Debian 5.0 is also what is being used for bugzilla AFAIK and so that might be a good option for consolidation. Who controls access to the Bugzilla server? I wouldn't mind having use of that as a bootstrap environment. Matt would know, but I suspect that shell access might be probably problematic to get and therefore unless we are talking about some continuous build system like cruisecontrol or hudson making snapshots, it might be problematic otherwise. to easy using one of those systems r2144 (still incomplete) was committed but would be nice to know which direction we are going anyway and for now it would seem there is not much dialogue going on about the alternatives. Access to that box probably isn't necessary, most people should have little difficulty getting their hands on a copy of lenny, and it is easy to install - any other comments on this? We also have access to the OpenCSW build farm, and they are willing to consider applications for access by Ganglia developers, so we could look at that as a bootstrap environment. Bootstrapping is done only once per package and so wouldn't make sense to also do bootstrapping in Solaris. No, I wasn't suggesting we bootstrap separately for Solaris. I was just suggesting that we use the OpenCSW machine to bootstrap for all platforms. However, we would be stuck with whatever version of autotools is current in the OpenCSW environment, and any decision to change the version there would be out of our control. I think Debian 5.0 (lenny) is the final decision then Debian 5.0 (lenny) x86 (32-bit) right? I'm using lenny amd64 (64 bit) most of the time now, especially since the various browser plugins (e.g. Java) now support 64 bit Linux. any final objections/comments? the only one I can think of is that we sometimes used to provide RPMs with the releases but that would be IMHO not that important considering that fedora/EPEL might be the package most people would use anyway and at least for fedora that
