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