[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2018-04-08 ] [098_ovirt_provider_ovn.use_ovn_provider]
Marcin Mirecki
mmirecki at redhat.com
Sun Apr 8 21:47:29 UTC 2018
Fix pending: https://gerrit.ovirt.org/#/c/89980/
On Sun, Apr 8, 2018 at 6:05 PM, Dan Kenigsberg <danken at redhat.com> wrote:
> On Sun, Apr 8, 2018 at 2:03 PM, Dan Kenigsberg <danken at redhat.com> wrote:
> > On Sun, Apr 8, 2018 at 1:40 PM, Barak Korren <bkorren at redhat.com> wrote:
> >> Test failed: 098_ovirt_provider_ovn.use_ovn_provider
> >>
> >> Link to suspected patches:
> >> https://gerrit.ovirt.org/#/c/89581/3
> >>
> >> Link to Job:
> >> https://gerrit.ovirt.org/#/c/89581/3
> >>
> >> Link to all logs:
> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/6714/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-098_ovirt_provider_ovn.py/
> >>
> >> Error snippet from log:
> >>
> >> <error>
> >>
> >> 'name'
> >> -------------------- >> begin captured logging << --------------------
> >> lago.providers.libvirt.cpu: DEBUG: numa
> >> : cpus_per_cell: 1, total_cells: 2
> >> lago.providers.libvirt.cpu: DEBUG: numa:
> >> <numa>
> >> <cell cpus="0" id="0" memory="1023" unit="MiB"/>
> >> <cell cpus="1" id="1" memory="1023" unit="MiB"/>
> >> </numa>
> >>
> >> lago.providers.libvirt.cpu: DEBUG: numa
> >> : cpus_per_cell: 1, total_cells: 2
> >> lago.providers.libvirt.cpu: DEBUG: numa:
> >> <numa>
> >> <cell cpus="0" id="0" memory="1023" unit="MiB"/>
> >> <cell cpus="1" id="1" memory="1023" unit="MiB"/>
> >> </numa>
> >>
> >> lago.providers.libvirt.cpu: DEBUG: numa
> >> : cpus_per_cell: 1, total_cells: 2
> >> lago.providers.libvirt.cpu: DEBUG: numa:
> >> <numa>
> >> <cell cpus="0" id="0" memory="2048" unit="MiB"/>
> >> <cell cpus="1" id="1" memory="2048" unit="MiB"/>
> >> </numa>
> >>
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> py.warnings: WARNING: * Unverified HTTPS request is being made.
> >> Adding certificate verification is strongly advised. See:
> >> https://urllib3.readthedocs.org/en/latest/security.html
> >> requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/tokens/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/networks/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/ports/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/subnets/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/networks/
> >> HTTP/1.1" 201 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/subnets/
> >> HTTP/1.1" 201 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/ports/
> >> HTTP/1.1" 201 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/networks/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/ports/
> >> HTTP/1.1" 200 None
> >> requests.packages.urllib3.connectionpool: INFO: * Starting new
> >> HTTPS connection (1): 192.168.201.4
> >> requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/subnets/
> >> HTTP/1.1" 200 None
> >> --------------------- >> end captured logging << ---------------------
> >>
> >> </error>
> >>
> >> Note: we're seeing similar issues on the same patches in both the
> >> 'master' and the 4.2 change queues.
> >
> >
> > I've tried to revert the suspected patch. Let us see if it makes OST
> happy again
> > http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2525/
>
> Indeed, the revert fixes OST.
> However, we can wait for Marcin to properly fix it the problem
> tomorrow. I don't think anybody but him needs green OST for
> ovirt-provider-ovn, so merging the revert can wait.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180408/5aaa2696/attachment.html>
More information about the Devel
mailing list