On Tue, 2007-11-06 at 05:06 -0800, john allspaw wrote:
While I love the idea of the python module, I'd like the plain-old
gmetric binary to stay as-is.
I agree. At least for the moment, I think it should remain. Perhaps at
some point in the future it could fade away, but at the present time
john allspaw wrote:
Hey all -
While I love the idea of the python module, I'd like the plain-old gmetric
binary to stay as-is. I'm not sure if there are/were plans on getting rid
of it in favor of the new custom framework stuff. Some of the reasons why I
think it should stay:
I also think
On 11/6/2007 at 11:26 AM, in message [EMAIL PROTECTED],
Christian Gouret [EMAIL PROTECTED] wrote:
Hello Brad,
I read the README pointed by the link you provide, and I see nothing
regarding the spoofing option introduced in the version 3.0.4 of Ganglia.
Does it mean that with python module,
I've been working on a list of ways to improve the PHP web frontend.
Just curious what every else thinks of these.
- add support for a caching layer for generated graphs
Add code that allows caching of generated graphs, either on the
filesystem or in a memcache cache. When generating a
[EMAIL PROTECTED] wrote:
I've been working on a list of ways to improve the PHP web frontend.
Just curious what every else thinks of these.
- add support for a caching layer for generated graphs
Add code that allows caching of generated graphs, either on the
filesystem or in a memcache
On 11/6/2007 at 1:45 PM, in message
[EMAIL PROTECTED], Matthias
Blankenhaus [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, john allspaw wrote:
Hey all -
While I love the idea of the python module, I'd like the plain-old gmetric
binary to stay as-is. I'm not sure if there are/were plans
Matthew Chambers wrote:
I don't know if I would call it difficult change, but it's a different
method of generating the graph. Currently rrdtool writes to standard
output and that gets sent straight to the client (after the HTTP
I'd forgotten that the graphs were generated on the fly. That
On Tue, 6 Nov 2007, Brad Nicholes wrote:
On 11/6/2007 at 1:45 PM, in message
[EMAIL PROTECTED], Matthias
Blankenhaus [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, john allspaw wrote:
Hey all -
While I love the idea of the python module, I'd like the plain-old gmetric
On Tue, 6 Nov 2007, Brad Nicholes wrote:
On 11/6/2007 at 1:50 PM, in message [EMAIL PROTECTED], Brad
Nicholes [EMAIL PROTECTED] wrote:
On 11/6/2007 at 1:45 PM, in message
[EMAIL PROTECTED], Matthias
Blankenhaus [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, john allspaw wrote:
So let me see if I understand this correctly. You have a main node which is
gathering metrics from the other cluster nodes through some other means than
gmond. Since your main node contains all of the metric data, your only problem
is pushing that data up through gmond on the main node to
On 11/6/2007 at 2:32 PM, in message
[EMAIL PROTECTED], Matthias
Blankenhaus [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, Brad Nicholes wrote:
On 11/6/2007 at 1:50 PM, in message [EMAIL PROTECTED], Brad
Nicholes [EMAIL PROTECTED] wrote:
On 11/6/2007 at 1:45 PM, in message
[EMAIL
Do we have any Rocks developers on this list?
The template for Rocks doesn't seem to be maintained any longer (at
least actively by any Ganglia developers since Federico left SDSC) so
I propose to delete this from our tree.
If no Rocks developers are on the list, could someone please forward
Hi Matthias:
On 11/6/07, Matthias Blankenhaus [EMAIL PROTECTED] wrote:
Right, so I cannot use that right now, as there is no 3.1.0 release code
yet and there is reluctance on SGI's side to go with non-release code.
Understood.
Well, if there is a chance for a 3.0.x release with the Python
Guys:
The first pre-alpha grin snapshot of 3.1.0 (aka code from trunk) is
now available for testing. This will most likely *not* reflect the
final version but basically acts as a quick test for the spec file
cleanup (which I just checked in) as well as a preview of Brad's hard
work on the
On Tue, Nov 06, 2007 at 04:59:59PM -0800, Bernard Li wrote:
Got a quick question about multicpu.conf -- by default, this is
installed with the RPM and enabled, should it be?
Because apparently, the kernel which comes with CentOS 4 does not
support it, as I get the following syslog message
15 matches
Mail list logo
