Re: [Ganglia-developers] PATCH : Adding trends to Ganglia
On Wed, Dec 16, 2009 at 1:18 PM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: On Tue, Dec 15, 2009 at 02:32:07PM +0100, Sebastien Termeau wrote: Dear Ganglia Developers, Please find below a patch that brings trends to Ganglia. Really interesting, would you mind filing and enhancement bug on www.ganglia.info?, that would be also a great place for attaching those images you said were also needed. Hi, Just to inform you that I have submitted 2 enhancement requests: http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=249 http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=250 They include patches for the trunk and the pictures. Best regards -- 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
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,
$ 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)
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?
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
--
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 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? 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. 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 - any final objections/comments? Should we a) after fixing the other showstopper (fork issue), do we tag 3.1.6 and let people test a tarball from Debian 5 autotools?, or b) make another 3.1.5 tarball using Debian 5 autotools, and put it in a separate location for people to test before we tag? Do we have a list of environments that must be tested after changing autotools again? -- 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] [RFC] two step gmond initialization
Carlo Marcelo Arenas Belon wrote: On Fri, Dec 18, 2009 at 04:18:16PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 13, 2009 at 10:49:00AM +, Daniel Pocock wrote: I could accept Brooks' solution, because it means gmond would only fail for something like out-of-memory, while any configuration failure, port in use, etc would cause it to fail before detaching. If gmond still fails silently in some cases, you have not accomplished the objective that you were trying to obtain with r2025 anyway. I agree - it doesn't completely meet my goal, but it does at least result in an error code for most types of bad configuration (or port in use) that part is OK, but you still have the added sideeffects of r2025 which would affect gmond in other interesting ways : * the metric (and module) initialization is now done by the parent and expected to be inherited by the child, this means for example that the parent will send (and receive) metric information (even before forking) * the suid is done by the parent and therefore the child isn't privileged (while the metric initialization was done as root), this would at least prevent anyone to bind gmond to privileged ports but also could result in complicated permission issues by metric collection scripts. as I said before I think the apr_poll issue with BSD should be taken as a warning of how the changes we were planning to do could have unintended sideeffects, and since moving the daemonization was only one way to solve the original problem, makes more sense to instead revert this change and evaluate alternatives. It is this line of argument, rather than the concerns about APR, that makes me think reverting the change completely might be the way to go for now, although the reason for the change is still a legitimate issue and can be tracked in bugzilla. Maybe this type of disruptive change will have to come in 3.2, there we can look at the various phases of initialisation more closely, prompt people to review their modules, etc. -- 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
