pcp
[Top] [All Lists]

Re: [pcp] qa/709 failing on Mac OS X - pmcollectl

To: Nathan Scott <nathans@xxxxxxxxxx>, Stan Cox <scox@xxxxxxxxxx>
Subject: Re: [pcp] qa/709 failing on Mac OS X - pmcollectl
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 23 Mar 2016 10:43:25 +1100
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1139238315.32024832.1458165274501.JavaMail.zimbra@xxxxxxxxxx>
References: <56E9CDDF.5080209@xxxxxxxxxxxxxxxx> <1139238315.32024832.1458165274501.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
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.

<Prev in Thread] Current Thread [Next in Thread>