----- Original Message -----
> Nathan,
>
> OK, thanks for all the feedback. Attached is hopefully a pmda
> ready for inclusion.
Looks good! Its merged now. I've updated the test a little too, please
check qa/798 in the dev branch of git://oss.sgi.com/pcp/pcp.git - you
can also run "./check -g pmda.nfsclient" and that will run all of the
nfsclient tests (if ever more are added, or if you don't want to have
to remember the test number).
Also, just realised there's no pmdanfsclient man page. The perl PMDAs
usually use the "pod" facility to do this - do you want to have a look
into this Martins? See src/pmdas/kvm/pmdakvm.pl for an example - it's
straight forward, we wont need more than that here I expect. Once the
pod stuff is in place, a small update to the makefile (see kvm again)
is also needed to ensure it becomes part of the pcp packages.
> I did my best on a qa test with a canned
> mountstats file. Maybe someone with more knowlege on what exactly should
> be tested for can add some more tests if necessary. Its unclear to me
> exactly why there are "???" instances, but the 716 test shows the same
> thing, so is that expected?
Very nice, thanks for doing the test. Yes, this is expected - the reason
is that dbpmda provides a very direct mapping (one-to-one to PDUs) to the
pmcd/pmda interface. For a fetch PDU - pmFetch(3) - we do not necessarily
have the instance names available, and only the internal IDs are returned
via a fetch. So, in this case, dbpmda will print "???" for those external
names.
The test exercises the indom lookup later on through, so we know that the
mapping works. Its good to keep the order you have there, as we do want
to test fetch PDUs arriving before instance PDUs, for example. I think if
the instance name lookup happens first, before fetch, dbpmda may be smart
enough to print out the names (i.e. it may cache them) ... not sure off
the top of my head though.
cheers.
--
Nathan
|