pcp
[Top] [All Lists]

Re: Some recent QA regressions

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Some recent QA regressions
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Tue, 15 Jul 2014 16:04:46 -0400
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1230657559.9961169.1405373957737.JavaMail.zimbra@xxxxxxxxxx>
References: <2129401188.6256039.1404891527704.JavaMail.zimbra@xxxxxxxxxx> <53C01477.6000703@xxxxxxxxxx> <1170491276.9256269.1405303222288.JavaMail.zimbra@xxxxxxxxxx> <53C4214F.4030405@xxxxxxxxxx> <1230657559.9961169.1405373957737.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
On 07/14/2014 05:39 PM, Nathan Scott wrote:
is 192.168.122.1 - for the 775 and 946 failures).
I'm not quite sure what to do about these two failures. They are
actually a problem with the tests themselves. As part of these tests,
the -r and --resolve options to pmfind(1) are tested, however, in this
case, the address 192.168.122.1 is an address on which a legitimate
service has been discovered, but for which the DNS resolution fails.
Because of this, it is reported unresolved and the filters in the tests
report a failure. I'm not quite sure how else to test whether the -r and
--resolve options were respected.
Could we verify the state of each host identifier returned using dig and
dig -x?  IOW, checking that those which can be resolved, are (comparing
libpcp and dig output), and those which cannot are not (pmfind vs dig -x)

brolley/dev in pcpfans ....

Dave

commit ceb06409cbbf4b7942c26713b1b7ac823bfa4810
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date:   Tue Jul 15 15:47:38 2014 -0400

Add a filter for ignoring unresolvable addresses for service discovery tests.

    The new file qa/common.discovery contains a new filter,
    _filter_discovery_unresolvable and moves other
    common code from individual tests as _filter_discovery_sought,
    _filter_discovery_resolved and _filter_discovery_unresolved.

    The new file is sourced by tests 775 and 946 which are fixed
    using the new _filter_discovery_unresolvable.

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