Hi Martins,
----- Original Message -----
> [...]
> Previously, the delegation had 2 requirements: The metric must (1) fall
> in the tree prefix and (2) be in the cluster list provided to
> pmdaDynamicPMNS. This prevented the same logic from handling related
> trees that differed in prefix (the hotproc.foo / proc.foo case ). Also,
> if a cluster spanned more than one sub-tree, only the first would be called.
*nod*
> In this reworked case, every check for handling a metric is checked
> against the generated pmns tree. I believe this should be safe,
> because as far as I can tell, the pmns must be setup before the metrics
> are created.
*nod*
> This allows the call to pmdaDynamicPMNS to be simplified. No check
> against a prefix or cluster is required. I didn't change the function
> call so as not to break existing code.
Good stuff.
> After this change, the prefix is
> only used to lookup the cluster mask if it is provided. I think the old
> cgroup pmda was the only user of the mask. Is this something that is
> still work keeping? If not, both the prefix and cluster parameters
> could be removed.
Yeah, we need to preserve API compatibility (even though no in-tree users
exist anymore).
> To do this, I had to expose an internal function in tree.c. Not sure if
> this is appropriate.
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.
> This change also exposed an inconsistancy I had previously noticed. DSO
> pmdas were not required to call pmdaTreeRebuildHash while daemon pmdas
> were. Now this call is required for both cases. I assume that whatever
That's a good thing IMO.
> fixup was occurring for the dso case is now not occurring early enough.
> I looked through existing pmdas and added the call to linux and gfs2,
> though I have no way to test gfs2.
>
> ./check -g pmda.linux
> ./check -g pmda.proc
>
> both Pass. I looked at the sample pmda and I think that it uses a
> different dynamic method that should not be affected. I have not fully
Yep.
> understood the new cgroups code yet, but I think that it should not be
> affected if I read it properly. Let me know if there would be any issue
> there.
There'll be no issues there.
> Let me know if there are any problems with this approach.
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.
cheers.
--
Nathan
|