pcp
[Top] [All Lists]

Re: [pcp] proposing pcp-3.6.0

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] proposing pcp-3.6.0
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 07 Apr 2011 20:39:03 +1000
Cc: Mark Goodwin <goodwinos@xxxxxxxxx>, "Frank Ch. Eigler" <fche@xxxxxxxxxx>, "dsm >> David Smith" <dsmith@xxxxxxxxxx>, pcp <pcp@xxxxxxxxxxx>
In-reply-to: <494075696.5497.1302159408796.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
References: <494075696.5497.1302159408796.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
Reply-to: kenj@xxxxxxxxxxxxxxxx
On Thu, 2011-04-07 at 16:56 +1000, Nathan Scott wrote:
> ----- Original Message -----
> > On 04/07/2011 02:40 PM, Mark Goodwin wrote:
> > ...
> > Is anyone using this yet (David?). Any creative thoughts to work
> > around it? Maybe we could keep this for the singular instance case:
> > pmUnpackEventRecords(pmValueSet *, pmResult ***)
> > and add a new API function for event metrics with an indom :
> > pmUnpackEventRecordsInstance(pmValueSet *, int, pmResult ***)
> > where pmUnpackEventRecords(v, r) would just call
> > pmUnpackEventRecordsInstance(v, 0, r).
> > 
> 
> Ken and I discussed this a couple of weeks ago, when I was talking
> about doing this exercise you're now doing (thanks!), and we were
> in agreement that we should just make the change since its a brand
> new API, in an area we declared "experimental and possibly going to
> change" during the last release.  Better to not start accumulating
> baggage at this early stage.
> 
> FWIW, I think 3.5.1 more apt than 3.6.0 here (theres nothing that
> big?).  I have a couple of little things pending, will finish and
> merge.  Should double check that Jeff's PMDA changes all landed in
> dev, I think they did.
> 
> cheers.

I agree with Nathan ... just make the API change, no one is using
pmUnpackEventRecords outside the PCP tree.

As to 3.6 vs 3.5.1 I don't care one way or the other.

As to commits, I think this is a more complete list of candidate commits
from my pcp4 branch (warning, long lines follow).

c2502b913f3182c67a1a4288d5f99bd1f7063200 pmlogger - auto volume switching at 
2^31 bytes
9fe10142a9af206b411ebb07f23524548124b638 pmnscomp - defaults to Version 2 of 
the compiled PMNS
22cadfcd74927f1c9eff12b97fd58913b7e6f2c5 pmlogextract - auto volume switching 
at 2^31 bytes
83126a29f8f54ad83fdacd6a5f6944374b60a456 pmlogextract, pmlogreduce - auto 
volume switch
91fd09c10f0ba9b836aeae2747374ce351f342e3 pmlogreduce - fix botch in 2^31 auto 
vol switch code
90f1532d20f2c57f43d5cac2662f47564c7a2e2f pmevent - report event records
948b9c03382b9fc6906fa18dba69a87b81d2f754 pmevent - interim checkin
ead8491c02a3401fde8f51b1e89e3d24e9dbb479 pmval - fix typo in error message
5ba51a2980bf63ad42baf9cdd279d7ddfe973697 indom services man pages - tweak
127752e2be4358d8d01068cf5ee0b7737cf7eb1a pmevent - getting closer
b5b8ba2172af8c4e252bb3736fd7b4d48e36ddfc retire PM_CLUSTER_EVENT - no longer 
needed

And Mark's list

fa60b6d594538294285a360fb1ebd277cbd74a2a pmval, pminfo - man page typo 
corrections
fbb0350513343361f8816e6ff9b99bd1ff07e0b8 event records - add instance domain 
support
ffe97dd82334686ca71099f8e1ba7befd2a2ef18 sample PMDA - instance domain for 
event records metric
e44575b312c3f464bab03c8c9210b0a48ab0e243 pmevent - add instance domain support

Can we agree?

And who's going to do the cherry-pick work?

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