pcp
[Top] [All Lists]

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

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] qa/709 failing on Mac OS X - pmcollectl
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 5 Apr 2016 22:41:15 -0400 (EDT)
Cc: Stan Cox <scox@xxxxxxxxxx>, PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <56F1D89D.90901@xxxxxxxxxxxxxxxx>
References: <56E9CDDF.5080209@xxxxxxxxxxxxxxxx> <1139238315.32024832.1458165274501.JavaMail.zimbra@xxxxxxxxxx> <56F1D89D.90901@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: EI30Y9BcWoEqpGBnh7gYL0fmDIASLw==
Thread-topic: qa/709 failing on Mac OS X - pmcollectl
Hi Ken,

----- Original Message -----
> [...]
> 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.

I don't think its a hugely common pattern there - looks like only reporting for
the network interface metrics (which we don't provide metric totals for, so it
looks like pcp-collectl.py does it itself) ... in which case, it may be easiest
if we just provide a little helper function for that situation.

See attached patch - uses a loop to avoid the TypeError, and keeps it all local
to the network metric reporting.  How does that fare with the QA test?

cheers.

--
Nathan

Attachment: pmcollectl.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [pcp] qa/709 failing on Mac OS X - pmcollectl, Nathan Scott <=