On 01/19/2015 02:15 PM, Ken McDonell wrote:
On 19/01/15 11:06, Mark Goodwin wrote:
On 01/17/2015 05:27 PM, Ken McDonell wrote:
[...]
This does not work at all "as is". It can be made to work, but that
involves
changing scores of source files ... the result is an ugly hack hiding
a git
branch and I'm not going to commit that to the dev branch.
On reflection, I think there are 2 alternatives:
1. change the default behaviour to allow duplicates and strip out all
the "no
duplicates" stuff, or
2. drop all pretence at supporting duplicate names and rip out the
associated
non-working stuff.
Thoughts?
I think it'd be good generally, ...
Is that a vote for 1.?
yes, my 2c :)
... and from the back compat viewpoint,
e.g. following namespace migrations and PMDA pmns updates, etc. But
how would pmTraversePMNS() work? What other problems are there?
There are no real problems. The PMNS is still a tree. Just that some of the
leaf nodes are labelled with the same PMID.
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.
- no changes at all to pmTraversePMNS() or pmLookupName()
- pmNameID() would return one name (man page already describes non-determinism
if PMNS contains duplicates)
- pmNameAll() would return all of the names ... and I'd change PCP apps that
currently use pmNameID() to use pmNameAll() and report all names for a given
PMID
The only change would be that if a PMDA implementor used the same PMID twice by
mistake, this would not be detected when the PMDA is installed, but would have
to be debugged when you ask for metric A and get answers back for metric B, ask
for metric B and get answers back for metric B.
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.
-- Mark
|