<div dir="ltr"><div>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 fqdn for the host ip.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski <span dir="ltr"><<a href="mailto:piotr.kliczewski@gmail.com" target="_blank">piotr.kliczewski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nadav,<br>
<br>
Thank you for working on this but we have one more issue with name 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>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com">pkliczew@redhat.com</a>> 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>
>> >> <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>
</div></div></blockquote></div><br></div>