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

It is green now. Thanks, Piotr On Sun, Apr 30, 2017 at 11:30 PM, Piotr Kliczewski wrote: > Thank you! > > 30 kwi 2017 23:14 "Nadav Goldin" napisał(a): > >> OK - that is easier as it involves only the master suite. Should be >> fixed in [1], in [2] is

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

Thank you! 30 kwi 2017 23:14 "Nadav Goldin" napisał(a): > OK - that is easier as it involves only the master suite. Should be > fixed in [1], in [2] is the test run. > > > [1] https://gerrit.ovirt.org/#/c/76251/ > [2]

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

OK - that is easier as it involves only the master suite. Should be fixed in [1], in [2] is the test run. [1] https://gerrit.ovirt.org/#/c/76251/ [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/342/console On Sun, Apr 30, 2017 at 10:39 PM, Piotr Kliczewski

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

I think it depends on which name we use when we add a host to the engine. We need to be consistent and use the same host name when adding a host and a fqdn for the host ip. On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski < piotr.kliczew...@gmail.com> wrote: > Nadav, > > Thank you for working

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

Nadav, Thank you for working on this but we have one more issue with name resolution. I checked the last job you triggered and I noticed that vm migration failed due to similar issue between the hosts. Here is a piece of custom logs that you added: 2017-04-30 14:23:35,675-0400 INFO (Reactor

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

Wow, great. Thank you! 30 kwi 2017 19:40 "Nadav Goldin" napisał(a): > Ok, I think the issue was the unqualified domain name. The certificate > was generated(as before for 'engine') without the domain name, i.e. > 'lago-basic-suite-master-engine', on VDSM side it resolved

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

Ok, I think the issue was the unqualified domain name. The certificate was generated(as before for 'engine') without the domain name, i.e. 'lago-basic-suite-master-engine', on VDSM side it resolved the IP to the address 'lago-basic-suite-master-engine.lago.local' and then failed comparing it to

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

Sure, will take look later today. 30 kwi 2017 18:47 "Nadav Goldin" napisał(a): > Thanks for the explanation. > > I added some more debugging messages on top of your patch, could you > please take a look at [1] and tell me what do you expect to resolve > differently for this

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

Thanks for the explanation. I added some more debugging messages on top of your patch, could you please take a look at [1] and tell me what do you expect to resolve differently for this to work? [1]

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

Nadav, Here is the code [1] which is responsible for this check. Here is vdsm log [2] where I added logging statement to understand what is commonName value (it was 'engine'). Here are the steps what is done during the check: 1. We get client peer name by calling socket.getpeername()[0] which

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

Looking at the failure, I'm not sure what is wrong here on the setup side. The FQDN(lago-basic-suite-master-engine) should be resolvable in the hosts - at least from what I tested that locally. On the engine setup.log I see this was the generated certificate(if we're talking about the same one

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

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 wrote: > Here is the link > > http://jenkins.ovirt.org/job/ovirt-system-tests_manual/331/ > > On Sun, Apr

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

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 wrote: > Sure, will test > > 30 kwi 2017 12:14 "Nadav Goldin" napisał(a): > >> It is under-work in [1], as it requires

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

Sure, will test 30 kwi 2017 12:14 "Nadav Goldin" 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

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

It was never there. When we use ssl module we perform a client certificate check which is not available in our m2crypto code. The check fails because the name we use in the certificate is not resolvable in OST. 30 kwi 2017 12:09 "Yaniv Kaul" napisał(a): > > > On Sun, Apr 30,

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

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]

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

On Sun, Apr 30, 2017 at 1:03 PM, Piotr Kliczewski < piotr.kliczew...@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

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

When we can have it fixed? I checked few minutes ago and the problem is still there. Thanks, Piotr On Sat, Apr 29, 2017 at 11:18 AM, Piotr Kliczewski wrote: > Nadav, > > Yes, vdsm is not able to resolve 'engine' which is used in engine's > certificate. > > Thanks, > Piotr >