pcp
[Top] [All Lists]

Re: [pcp] Culling code from libpcp

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] Culling code from libpcp
From: Max Matveev <makc@xxxxxxxxx>
Date: Thu, 6 May 2010 22:32:56 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1273094842.22330.107.camel@xxxxxxxxxxxxxxxx>
References: <1273009170.22330.53.camel@xxxxxxxxxxxxxxxx> <19425.17389.939551.768071@xxxxxxxxxxxx> <1273094842.22330.107.camel@xxxxxxxxxxxxxxxx>
On Thu, 06 May 2010 07:27:22 +1000, Ken McDonell wrote:

 kenj> On Wed, 2010-05-05 at 20:09 +1000, Max Matveev wrote:
 >> On Wed, 05 May 2010 07:39:30 +1000, Ken McDonell wrote:

 kenj> 2. the routines are not used by pmchart
 >> Which is probably a fault of pmchart, neh?

 kenj> No ... if one separates the UI event-driven goo from the sync PCP glop
 kenj> things tend to "just work".
As gnb has said, if there a sudden drop in TCP or if pmcd on one of
the hosts takes a bit too long to extract metrics then it just stops
working and attempts to catch up later by skipping all hosts just to
cater for a slow one.

 kenj> I have a philosophical objection to bloat ... so if we're including code
 kenj> that no one is using it should be removed ... in this case it seems that
 kenj> there are some pockets of use outside the open source PCP code so the
 kenj> precondition is not met.
Speaking of bloat - I've got a unfinished wireshark dissector written
in Lua which can grok PCP protocol and display if nicely when added to
Lua-enabled wireshark and I'm looking for a home for it. Should I park
it somewhere in the pcp tree or is there a better place for it?

 kenj> But if we're going to keep the code then having no QA coverage is a very
 kenj> large risk.  The recent derived metrics and dynamic metrics in the PMNS
 kenj> involved lobotomizing big chunks of pmns.c, and if the async stuff still
 kenj> works or works at all with derived and dynamic metrics that will be good
 kenj> luck rather than good management. 

 kenj> So if the code is going to stay, I suggest it is up to those who are
 kenj> dependent on the async routines to pitch in and offer some assistance to
 kenj> expand the QA coverage (at least from a selfish point of view for the
 kenj> parts of the functionality they care about or depend upon).
I'll see what I can do in this area once the current leg of the death
march is over. 

I was sure there were an example program which was using async API but
maybe it was stuck in some dusty non-PCP tree inside SGI, so worse
case I'd have to write it again. And the best case may be that I can
bolt in to pmchart.

Now, where was that sword again...

max

<Prev in Thread] Current Thread [Next in Thread>