[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]

[Piotr Kliczewski]

It is green now.

Thanks,
Piotr

On Sun, Apr 30, 2017 at 11:30 PM, Piotr Kliczewski <pkliczew at redhat.com>
wrote:

> Thank you!
>
> 30 kwi 2017 23:14 "Nadav Goldin" <ngoldin at redhat.com> napisał(a):
>
>> OK - that is easier as it involves only the master suite. Should be
>> fixed in [1], in [2] is the test run.
>>
>>
>> [1] https://gerrit.ovirt.org/#/c/76251/
>> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/342/console
>>
>>
>> On Sun, Apr 30, 2017 at 10:39 PM, Piotr Kliczewski <pkliczew at redhat.com>
>> wrote:
>> > I think it depends on which name we use when we add a host to the
>> engine.
>> > We need to be consistent and use the same host name when adding a host
>> and a
>> > fqdn for the host ip.
>> >
>> > On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski
>> > <piotr.kliczewski at gmail.com> wrote:
>> >>
>> >> Nadav,
>> >>
>> >> Thank you for working on this but we have one more issue with name
>> >> resolution.
>> >>
>> >> I checked the last job you triggered and I noticed that vm migration
>> >> failed due to similar issue between the hosts.
>> >> Here is a piece of custom logs that you added:
>> >>
>> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
>> >> ((('organizationName', u'Test'),), (('commonName',
>> >> u'lago-basic-suite-master-host0'),)), key: organizationName, value:
>> >> Test (sslutils:241)
>> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
>> >> ((('organizationName', u'Test'),), (('commonName',
>> >> u'lago-basic-suite-master-host0'),)), key: commonName, value:
>> >> lago-basic-suite-master-host0 (sslutils:241)
>> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr:
>> >> ::ffff:192.168.201.2, cn_addr: lago-basic-suite-master-host0
>> >> (sslutils:262)
>> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr_extracted:
>> >> 192.168.201.2, cn_addr_extracted: lago-basic-suite-master-host0
>> >> (sslutils:266)
>> >> 2017-04-30 14:23:35,677-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher]
>> >> socket.gethostbyadd(src_addr)[0]:
>> >> lago-basic-suite-master-host0.lago.local (sslutils:268)
>> >> 2017-04-30 14:23:35,678-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] compare
>> >> ::ffff:192.168.201.2, lago-basic-suite-master-host0, res: False
>> >> (sslutils:244)
>> >> 2017-04-30 14:23:35,678-0400 ERROR (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] peer certificate does not
>> >> match host name (sslutils:226)
>> >>
>> >> It looks like the engine issued certificate for
>> >> 'lago-basic-suite-master-host0' but we resolve 192.168.201.2 to
>> >> 'lago-basic-suite-master-host0.lago.local'.
>> >> Can we fix it as well?
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >> On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <pkliczew at redhat.com
>> >
>> >> wrote:
>> >> > Wow, great.
>> >> >
>> >> > Thank you!
>> >> >
>> >> > 30 kwi 2017 19:40 "Nadav Goldin" <ngoldin at redhat.com> napisał(a):
>> >> >>
>> >> >> Ok, I think the issue was the unqualified domain name. The
>> certificate
>> >> >> was generated(as before for 'engine') without the domain name, i.e.
>> >> >> 'lago-basic-suite-master-engine', on VDSM side it resolved the IP
>> to
>> >> >> the address 'lago-basic-suite-master-engine.lago.local' and then
>> >> >> failed comparing it to the unqualified one. I assume this is the
>> >> >> expected behaviour, though not sure(as you can easily resolve
>> >> >> 'lago-basic-suite-master-engine' to
>> >> >> 'lago-basic-suite-master-engine.lago.local' on the hosts). It
>> should
>> >> >> be fixed in [1], just ran OST manual with the same debugging patch
>> >> >> applied on top of yours, and at least add_hosts passed.
>> >> >>
>> >> >>
>> >> >> [1] https://gerrit.ovirt.org/#/c/76225/10
>> >> >> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/338/c
>> onsole
>> >> >>
>> >> >> On Sun, Apr 30, 2017 at 7:50 PM, Piotr Kliczewski <
>> pkliczew at redhat.com>
>> >> >> wrote:
>> >> >> > Sure, will take look later today.
>> >> >> >
>> >> >> > 30 kwi 2017 18:47 "Nadav Goldin" <ngoldin at redhat.com> napisał(a):
>> >> >> >>
>> >> >> >> Thanks for the explanation.
>> >> >> >>
>> >> >> >> I added some more debugging messages on top of your patch, could
>> you
>> >> >> >> please take a look at [1] and tell me what do you expect to
>> resolve
>> >> >> >> differently for this to work?
>> >> >> >>
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/337/a
>> rtifact/exported-artifacts/test_logs/basic-suite-master/post
>> -002_bootstrap.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20170430/7f31b697/attachment-0001.html>