Hi Dave,
----- Original Message -----
> On 07/13/2014 10:00 PM, Nathan Scott wrote:
> > Ah, OK, sounds promising. From a full QA run though I have new failures
> > in tests 230, 775, 835, and 946 that all appear related to these changes.
> >
> > 835 is the new pmdamemcache test, but it was running reliably on Friday
> > - with the latest pull, not so much (it now times-out during the initial
> > pmcd connection).
> OK. Sorry about that. It turns out that expecting callers of
> __pmConnect() to handle EIPROGRESS with no timeout was the wrong way to
> go. It turns out that callers who expect non-blocking connections always
> call __pmConnectTo() which sets the FNDELAY flag and that callers who
> expect blocking connections call __pmConnect() directly. So what is
> really needed is for __pmConnect() and __pmConnectTo() to provide the
> expected semantics. The commit below does that once and for all.
OK - great, thanks Dave.
> It fixes test 230 for me, but I don't seem to be set properly to run
> test 835 ([not run] Noones home on the default memcached port 11211)
Ah sorry, details re this were in one of the other mails (chatting to
Chandana) - if you "yum install memcached && service memcached start"
you'll have something to talk to on that port.
Sounds like you've nailed it though, I'll verify later today - thanks.
> > 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)
cheers.
--
Nathan
|