Sometime over the next 5 weeks it would be good to get an answer to my
questions below, so that I can fix it when I'm back in PCPland.
Cheers, Ken.
On 23/03/16 10:43, Ken McDonell wrote:
On 17/03/16 08:54, Nathan Scott wrote:
Hi Ken,
----- Original Message -----
There are no network.interface.in.compressed metrics from the darwin PMDA,
leading to ...
! Traceback (most recent call last):
! File "/usr/local/bin/pmcollectl", line 9, in <module>
! ssx.print_line()
! File "/usr/local/bin/pmcollectl", line 9, in print_line
! self.print_verbose()
! File "/usr/local/bin/pmcollectl", line 9, in print_verbose
! sum(self.ss.get_metric_value('network.interface.in.compressed')),
! TypeError: 'int' object is not iterable
My questions are:
(a) should pmcollectl handle this case correctly?
Yep, I think it should - looks like a bug.
I'm back looking at this one.
It appears that get_metric_value() is returning a scalar value of 0 when values
are not available for the metric ... this is sort of a problem when the caller
wraps this in sum(...) because scalar 0 is not iterable.
I explored fixing this in get_metric_value() but we have no way to decide if we
should return 0 or [0] there because if the metric is not defined there is no
pmDesc.
So, I think the caller has to test, and this leads to this ugliness:
try:
sum_compressed =
sum(self.ss.get_metric_value('network.interface.in.compressed'))
except TypeError as te: # pylint: disable-msg=C0103
sum_compressed = 0
Is this the best one can do? Is the pyrlint chatter needed?
If so, we'll end up with these turdlets throughout the code in every place
where a function assuming an iterable is used with an argument that comes from
a get_metric_value() call that might involve a metric that is not available.
_______________________________________________
pcp mailing list
pcp@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/pcp
|