Description of problem: When host is not defined one would expect it being the localhost. localhost:~> pmdumptext -i -l 'rhel-6-server:mem.util.used' 'mem.util.used' Source rhel-6 rhel-6 Thu Aug 21 13:51:41 0.45G 0.45G ^C localhost:~> pmdumptext -i -l 'rhel-6-server:mem.util.used' 'localhost:mem.util.used' Source rhel-6 localh Thu Aug 21 13:51:45 0.45G 5.54G ^C localhost:~> Version-Release number of selected component (if applicable): 3.9.9
To be clear, the problem here appears to be that the "default" context is being redefined by the first metricspec (rhel-6-server:mem.util.used) to be rhel-6-server, rather than localhost. This mirrors the behaviour of -h, e.g. pmdumptext -h rhel-6-server some.metric mem.util.used would report mem.util.used from rhel-6-server not localhost. I am not sure of the correct behaviour here (although the status quo does not follow the law of least surprise) and there are no other command-line tools that allow metricspecs and more than one source of metrics.
> ... (although the status quo does not follow the law of least surprise) and > there are no other command-line tools that allow metricspecs and more than > one source of metrics. I agree - this seems wrong, and looks like it will have several unexpected side-effects. It looks like the way the traverse() function overwrites some globals (doMetricType, doMetricSource, doMetricScale) is the root cause - making these locals within traverse() might go a long way toward fixing this.
Actually, I incorrectly thought pmdumptext could work with more than one host at once, but it turns out it cannot (creates only one QmcGroup object, and has code early on that attempts to guard against multiple hosts - but misses the case where more than one host can come in via use of metricspecs). I guess we need to add more cases to ensure additional hosts/archives are not passed in this way?
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version, you are encouraged to change the 'version' to a later version prior this bug is closed as described in the policy above.
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I know it is almost 6 years ago, but I was looking at this issue and ... First, pmdumptext can handle multiple host sources. I reworked the pmdumptext code so that: $ pmdumptext metric host:metric and $ pmdumptext host:metric metric fetched metric from host and local: (assuming "host" was not localhost, `hostname`, local: or some related alias) in both cases and produced similar output (albeit with the columns permuted). But then when I tried to craft words for the man page to explain the "new" behaviour I realized that (a) it was really hard to explain, and (b) this change introduces special case logic to modify the behaviour of the underlying libpcp_qmc routines, so this "new" behaviour would be a pmdumptext-only exception. Consequently I undid the code change to revert to the original behaviour, but added new words in the man page to explain what is happening ... FYI here are those words: When a metric does not contain a host: or archive/ prefix, e.g. ker‐ nel.all.cpu.idle above, then the source of the metric is determined by the following rules: (a) PMCD on host from the -h option if any, else (b) the archive from the first -a option if any, else (c) the host from the first metric prior to this one with a host: pre‐ fix if any, else (d) the archive from the first metric prior to this one with an ar‐ chive/ prefix if any, else (e) PMCD on the local host, which is equivalent to local::metric. Marco's 1st case follows rule (c), and his 2nd case does not require any of these rules as each argument has a host: prefix. If he'd added a 3rd case: $ pmdumptext -i -l 'mem.util.used' 'rhel-6-server:mem.util.used' which has the arguments from case 1 swapped, this would follow rule (e). Commit c5836fb93 has the man page change to explain what's happening and a new qa test (qa/1844) to exercise all the permutations.