Sure, will test 30 kwi 2017 12:14 "Nadav Goldin" <ngoldin@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@redhat.com> wrote:
On Sun, Apr 30, 2017 at 1:03 PM, Piotr Kliczewski <piotr.kliczewski@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@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@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 <
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@redhat.com> pkliczew@redhat.com>
wrote:
On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin <ederevea@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_
master/6491/
> > VDSM log: > > > > http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ master/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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel