Hi Martins,
----- Original Message -----
> Nathan,
>
> Thanks for the review.
No problem at all.
> On 12/8/14 7:16 PM, Nathan Scott wrote:
> > S'fine by me. Since its no longer static, we should rename it to follow
> > the PMDA library externally-visible-symbols conventions - (no double __,
> > for both function and data structure names - the latter is covered, but
> > do the former too). src/libpcp_pmda/src/exports will also need tweaking.
> I assume you mean add a new version (PCP_PMDA_3.4) at the bottom for
> this new export?
Yep.
> > I'm seeing a QA failure in test 660 - pmwebd is not seeing all of the names
> > for the interrupts metrics... (need to edit src/test_webapi.py to add debug
> > statements back in - commented out - this test needs some love to make it a
> > bit easier to diagnose these kinds of problems).
> >
> > Is that one failing for you? If not, I can dig more - I guess its not in
> > either of those two test groups (linux/proc) above.
> Yeah, I wasn't building pmwebd on this host. Got that up and running.
> Looks like the error is coming from:
>
> pmwebapi.cxx -> metric_list_traverse
>
> The call to pmLookupDesc is failing on dynamic metrics. But the PMNS has
> already been traversed successfully for them. Ran out of time today, I
> will dig deeper tomorrow. My guess is I missed a call to populate the
> metric table for some case.
>
> I assume there is some order that is different in terms of what the
> web-api does from the standard command line tools.
Yeah that'd be my guess too. If you're up for it, 660 could be split into
two - one that does the python part and another that does the rest - it'll
help with narrowing this down (the failure is in the python part, but you
get to wait the full ~30 seconds or so on each test iteration).
The python code also needs to be modified to always create the diagnostic
files needed to triage this class of failure (actually, I've got that fix
locally already from my initial look into this - I'll merge that shortly).
But I've got a note to return to this test to further split it up, if you
don't get to it as part of this work then don't worry about it.
> pminfo/pmval appear to work fine.
Yes, pmwebd is quite unusual (& unfortunately quite inefficient) in terms
of the pcp protocol requests it makes - eg see the pmLookupDesc/pmNameID
calls within the fetch decoding loop - its unique in at least this area.
cheers.
--
Nathan
|