On 19/01/15 16:38, Mark Goodwin wrote:
...
yes it's still a tree and there are no cycles, but I was thinking
more about the subtle change in semantics for pmTraversePMNS(),
where the assumption was each metric in the named subtree would
receive exactly one callback - that would now only be true for
each leaf node / name in the PMNS, not each metric (many names
to one metric). Maybe that's not a problem.
Depending on how you squint, pmTravsePMNS() really only guarantees one
callback per leaf node below the root of the search ... this would still
be true and different names would (possibly) be returned for metrics
with the same PMID.
So, I don't think that is an issue. Most clients would treat this no
differently to the same metric being named twice on the command line or
in a config file.
we could provide a simple tool to list the duplicate pmIDs in a subtree
for this, and I guess qa tests to verify what the developer was expecting.
Good idea, and it could be used to emit a warning from the Install
scripts which would trigger qa failures if this was introduced as a
regression in an existing PMDA.
|