The job failed.
Just to be clear. We need to resolve engine name on a host side or use ip
address.
Thanks,
Piotr
On Sun, Apr 30, 2017 at 12:23 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
wrote:
Here is the link
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/331/
On Sun, Apr 30, 2017 at 12:17 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
wrote:
> Sure, will test
>
> 30 kwi 2017 12:14 "Nadav Goldin" <ngoldin(a)redhat.com> napisał(a):
>
>> It is under-work in [1], as it requires cross-changes in all suites it
>> takes a while to test it/cover all changes, though basic-suite-master
>> already passed.
>> Can you test it by running OST manual with your changes and the OST
>> patch(i.e. put also in GERRIT_REFSPEC: refs/changes/25/76225/7 )
>>
>>
>>
>> [1]
https://gerrit.ovirt.org/76225
>>
>> On Sun, Apr 30, 2017 at 1:09 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>> >
>> >
>> > On Sun, Apr 30, 2017 at 1:03 PM, Piotr Kliczewski
>> > <piotr.kliczewski(a)gmail.com> wrote:
>> >>
>> >> When we can have it fixed? I checked few minutes ago and the problem
>> >> is still there.
>> >
>> >
>> >
https://gerrit.ovirt.org/#/c/76225/ should cover this.
>> >
>> > What I wonder is what caused this in the first place. The SSL change?
>> > Y.
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >> On Sat, Apr 29, 2017 at 11:18 AM, Piotr Kliczewski <
>> pkliczew(a)redhat.com>
>> >> wrote:
>> >> > Nadav,
>> >> >
>> >> > Yes, vdsm is not able to resolve 'engine' which is used in
engine's
>> >> > certificate.
>> >> >
>> >> > Thanks,
>> >> > Piotr
>> >> >
>> >> > 29 kwi 2017 00:37 "Nadav Goldin"
<ngoldin(a)redhat.com> napisał(a):
>> >> >
>> >> > Hi Piotr,
>> >> > Can you clarify what you noticed is not resolvable - the
'engine'
>> FQDN
>> >> > from host0?
>> >> >
>> >> > Thanks,
>> >> > Nadav.
>> >> >
>> >> >
>> >> > On Fri, Apr 28, 2017 at 4:15 PM, Piotr Kliczewski <
>> pkliczew(a)redhat.com>
>> >> > wrote:
>> >> >> I started to investigate the issue [1] and it seems like there
is
>> an
>> >> >> issue
>> >> >> in Lago setup we use.
>> >> >>
>> >> >> During handshake we have a step to verify whether client
>> certificate
>> >> >> was
>> >> >> issued for a specific host (no such functionality in m2crytpo
code
>> >> >> base).
>> >> >> It works fine when using either ip addresses or fqdns but in
this
>> >> >> particular
>> >> >> setup we use mixed.
>> >> >>
>> >> >> When added logging I see that in engine certificate we use
'engine'
>> >> >> name
>> >> >> which is not resolvable on the host side and the check fails.
>> >> >> I posted a patch [2] which fixes IPv4 mapped addresses issue
but we
>> >> >> need
>> >> >> to
>> >> >> fix the setup issue.
>> >> >>
>> >> >> Thanks,
>> >> >> Piotr
>> >> >>
>> >> >> [1]
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/326/
>> >> >> [2]
https://gerrit.ovirt.org/#/c/76197/
>> >> >>
>> >> >> On Thu, Apr 27, 2017 at 3:39 PM, Piotr Kliczewski <
>> pkliczew(a)redhat.com>
>> >> >> wrote:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin
>> >> >>> <ederevea(a)redhat.com> wrote:
>> >> >>>>
>> >> >>>> Test failed: 002_bootstrap/add_hosts
>> >> >>>>
>> >> >>>> Link to suspected patches:
>> >> >>>>
https://gerrit.ovirt.org/76107 - ssl: change default
library
>> >> >>>>
>> >> >>>> Link to job:
>> >> >>>>
>> >> >>>>
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/6491/
>> >> >>>>
>> >> >>>> VDSM log:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/6491/artifact/exported-artifacts/basic-suit-master-el7/
>> test_logs/basic-suite-master/post-002_bootstrap.py/lago-basi
>> c-suite-master-host0/_var_log/vdsm/vdsm.log
>> >> >>>>
>> >> >>>> Error snippet from VDSM log, this repeats on each
connection
>> attempt
>> >> >>>> from
>> >> >>>> Engine side:
>> >> >>>>
>> >> >>>> <error>
>> >> >>>>
>> >> >>>> 2017-04-27 06:39:27,768-0400 INFO (Reactor thread)
>> >> >>>> [ProtocolDetector.AcceptorImpl] Accepted connection
from
>> >> >>>> ::ffff:192.168.201.3:49530 (protocoldetector:74)
>> >> >>>> 2017-04-27 06:39:27,898-0400 ERROR (Reactor thread)
>> [vds.dispatcher]
>> >> >>>> uncaptured python exception, closing channel
>> >> >>>> <yajsonrpc.betterAsyncore.Dispatcher connected
>> >> >>>> ('::ffff:192.168.201.3',
>> >> >>>> 49530, 0, 0) at 0x1cc3b00> (<class
'socket.error'>:Address
>> family not
>> >> >>>> supported by protocol
>> >> >>>> [/usr/lib64/python2.7/asyncore.py|readwrite|110]
>> >> >>>>
[/usr/lib64/python2.7/asyncore.py|handle_write_event|468]
>> >> >>>>
>> >> >>>>
>> >> >>>>
[/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.p
>> y|handle_write|70]
>> >> >>>>
>> >> >>>>
>> >> >>>>
[/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.p
>> y|_delegate_call|149]
>> >> >>>>
[/usr/lib/python2.7/site-packages/vdsm/sslutils.py|handle_wr
>> ite|213]
>> >> >>>>
[/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_handle_i
>> o|223]
>> >> >>>>
[/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_verify_h
>> ost|237]
>> >> >>>>
>> >> >>>>
[/usr/lib/python2.7/site-packages/vdsm/sslutils.py|compare_n
>> ames|249])
>> >> >>>> (betterAsyncore:160)
>> >> >>>>
>> >> >>>> </error>
>> >> >>>
>> >> >>>
>> >> >>> This means that what we have in the certificate do not
match the
>> >> >>> source
>> >> >>> address we get. I suspect that we issue the certificate
for
>> >> >>> 192.168.201.3
>> >> >>> but when we get ::ffff:192.168.201.3.
>> >> >>> The change was verified in the env when ipv4 is used. I
pushed a
>> >> >>> revert
>> >> >>> [1] for now so we can work on fixing the issue.
>> >> >>>
>> >> >>> [1]
https://gerrit.ovirt.org/#/c/76160
>> >> >>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Regards,
>> >> >>>> Evgheni Dereveanchin
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Devel mailing list
>> >> >> Devel(a)ovirt.org
>> >> >>
http://lists.ovirt.org/mailman/listinfo/devel
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Devel mailing list
>> >> > Devel(a)ovirt.org
>> >> >
http://lists.ovirt.org/mailman/listinfo/devel
>> >> _______________________________________________
>> >> Devel mailing list
>> >> Devel(a)ovirt.org
>> >>
http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel(a)ovirt.org
>> >
http://lists.ovirt.org/mailman/listinfo/devel
>>
>