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

Sure, will test 30 kwi 2017 12:14 "Nadav Goldin" <ngoldin(a)redhat.com&gt; 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&gt; wrote: > > > > > > On Sun, Apr 30, 2017 at 1:03 PM, Piotr Kliczewski > > <piotr.kliczewski(a)gmail.com&gt; 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&gt; > >> 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&gt; 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&gt; > >> > 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&gt; > >> >> wrote: > >> >>> > >> >>> > >> >>> > >> >>> On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin > >> >>> <ederevea(a)redhat.com&gt; 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- > basic-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. > py|handle_write|70] > >> >>>> > >> >>>> > >> >>>> [/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore. > py|_delegate_call|149] > >> >>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|handle_ > write|213] > >> >>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_handle_ > io|223] > >> >>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_verify_ > host|237] > >> >>>> > >> >>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|compare_ > names|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 >