----- Original Message -----
> Hi,
>
> Below is the first cut to convert pmrep to use pmfg. It's not yet
Well played.
> intended for merging as there are quite a few QA failures but to kick
> off discussion are we talking about pmfg, pmrep, or some other issues
> with those QA failures.
You might want to check in with Mark (mgoodwin) when he's back, he was
looking to stitch pmOption handling up to the fetchgroup API a little
while ago - not sure where he got to.
>
> Current issues:
>
> - pmfg rejects metrics like pmcd.pmie.configfile which pmval/pmrep/etc
> accept
Hmm, I wonder what it is about that metric it doesn't like - does it also
reject sample.noinst? If so, that's possibly a pmfg bug - metrics can at
any time have no values, then some values, then none again.
> - in QA 1062 (vmstat-like output) idleness was previously reported
> correctly (~99), now it get some insanely high value (115646464) which
> gets truncated. Might also be incorrect scale parameter.
> - QA 1068 output is different, haven't investigated yet
> - in QA 1069 for sample.seconds we get 1 (integer) unlike with
> pmval/pmrep which give typically something like ~0.999-1.001 and for
> sample.milliseconds we get ~1000.002 or such where pmval/pmrep report
> ~1.000.
This may be conversion to a "time utilization" I guess - so the value
reported will be in units of seconds-per-second - i.e. between 0 and 1
for those metrics.
> - in QA 1070 earlier 0.500/0.000 is now 0 (just noticed this, haven't
> investigated much)
> - in QA 1071 a similar as with 1070
Its great to see the QA tests being used to such good effect!
> So overall things looks pretty good, it might well be a one-liner or
> two in pmrep and/or pmfg and we'd see QA passing. I'll certainly
> continue investigating but if can think of any explanation for the
> above hickups, please let me now.
cheers.
--
Nathan
|