* [libvirt test] 129491: regressions - FAIL
@ 2018-11-08 3:42 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2018-11-08 3:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 129491 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt 6 libvirt-build fail REGR. vs. 129353
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 129353
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 129353
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass
test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass
version targeted for testing:
libvirt 4f1107614dc1384c4aa7a5582a16aecba8b9310f
baseline version:
libvirt 48080527d6e364f213affd8517bb99a665d38440
Last test of basis 129353 2018-11-03 04:18:56 Z 4 days
Failing since 129434 2018-11-05 04:19:08 Z 2 days 2 attempts
Testing same since 129491 2018-11-06 04:18:40 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Daniel Veillard <veillard@redhat.com>
John Ferlan <jferlan@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt fail
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm blocked
test-amd64-amd64-libvirt pass
test-arm64-arm64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt blocked
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair blocked
test-arm64-arm64-libvirt-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-amd64-libvirt-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 4f1107614dc1384c4aa7a5582a16aecba8b9310f
Author: John Ferlan <jferlan@redhat.com>
Date: Sun Sep 23 11:56:46 2018 -0400
docs: Enhance polkit documentation to describe secondary connection
https://bugzilla.redhat.com/show_bug.cgi?id=1631606
Since commit 8259255 usage of a primary connection driver for
a virConnect has been modified to open (virConnectOpen) and use
a connection to the specific driver in order to handle the API
calls to/for that driver. This causes some confusion and issues
for ACL polkit rule scripts to know exactly which driver by
name will be used.
Add some documentation describing the processing of the primary
and secondary connection as well as the list of the connect_driver
names used for each driver.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
commit ccc72d5cbdd85f66cb737134b3be40aac1df03ef
Author: John Ferlan <jferlan@redhat.com>
Date: Sun Oct 14 10:09:32 2018 -0400
access: Modify the VIR_ERR_ACCESS_DENIED to include driverName
https://bugzilla.redhat.com/show_bug.cgi?id=1631606
Changes made to manage and utilize a secondary connection
driver to APIs outside the scope of the primary connection
driver have resulted in some confusion processing polkit rules
since the simple "access denied" error message doesn't provide
enough of a clue when combined with the "authentication failed:
access denied by policy" as to which connection driver refused
or failed the ACL check.
In order to provide some context, let's modify the existing
"access denied" error returne from the various vir*EnsureACL
API's to provide the connection driver name that is causing
the failure. This should provide the context for writing the
polkit rules that would allow access via the driver.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
commit 67125e0d336ffca1c8dfeb058e3f7217d56c1642
Author: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Date: Mon Oct 15 11:26:28 2018 +0300
nwfilter: Instantiate active filter bindings during driver init
Commit 57f5621f modified nwfilterInstantiateFilter to detect when
a filter binding was already present before attempting to add the
new binding and instantiate it. Additionally, the change to
nwfilterStateInitialize to call virNWFilterBindingObjListLoadAllConfigs
(from commit c21679fa3f) to load active domain filter bindings, but
not instantiate them eventually leads to a problem for the QEMU
driver reconnection logic after a daemon restart where the filter
bindings would no longer be instantiated.
Subsequent commit f14c37ce4c replaced the nwfilterInstantiateFilter
with virDomainConfNWFilterInstantiate which uses @ignoreExists to
detect presence of the filter and still did not restore the filter
instantiation call when making the new nwfilter bindings logic active.
Thus in order to instantiate any active domain filter, we will call
virNWFilterBuildAll with 'false' to indicate the need to go through
all the active bindings calling virNWFilterInstantiateFilter to
instantiate the filter bindings.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
commit 29183778af488870ed09bb2239740f5d6cdba68b
Author: John Ferlan <jferlan@redhat.com>
Date: Thu Oct 18 10:22:18 2018 -0400
nodedev: Document the udevEventHandleThread
Commit cdbe1332 neglected to document the API. So let's add some
details about the algorithm and why it was used to help future
readers understand the issues encountered.
NB: Management of the processing udev device notification is a
delicate balance between the udev process, the scheduler, and when
exactly the data from/for the socket is received. The balance is
particularly important for environments when multiple devices are
added into the system more or less simultaneously such as is done
for mdev or SRIOV. In these cases old libudev blocking on the udev
recv() occurs more frequently. It's expected that future devices
will follow similar algorithms. Even though the algorithm does
present some challenges for older OS's (such as Centos 6), trying
to rewrite the algorithm to fit both models would be more complex
and involve pulling the monitor object out of the private data
lockable object and would need to be guarded by a separate lock.
Devising such an algorithm to work around issues with older OS's
at the expense of more modern OS algorithms in newer event processing
code may result in unexpected issues, so the choice is to encourage
use of newer OS's with newer udev event processing code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
commit 4de4e4bc991158ea2a881d4729a668b2eb5fe83a
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Nov 1 18:21:12 2018 +0100
qemu: Dissolve qemuBuildVhostuserCommandLine in qemuBuildInterfaceCommandLine
https://bugzilla.redhat.com/show_bug.cgi?id=1524230
The qemuBuildVhostuserCommandLine builds command line for
vhostuser type interfaces. It is duplicating some code of the
function it is called from (qemuBuildInterfaceCommandLine)
because of the way it's called. If we merge it into the caller
not only we save a few lines but we also enable checks that we
would have to duplicate otherwise (e.g. QoS availability).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
commit e7b7b617689ab6fff49b16b96aa417bf2382e79b
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Fri Nov 2 16:12:45 2018 +0100
qemuBuildInterfaceCommandLine: Reorder VIR_FREE
When we have variables A, B, C then there are two ways to free
them. Either in the order they are declared or the reversed one.
Any other ordering is confusing. In this commit I'm reordering
calls to VIR_FREE in the reversed order.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
commit 18f90481cd47354cd834053b5bf12869f7afc8b6
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Mon Nov 5 08:46:39 2018 +0100
Post-release version bump to 4.10.0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit 7a10a6a598ab4e8599c867060a7232a06c663e51
Author: Daniel Veillard <veillard@redhat.com>
Date: Sun Nov 4 17:50:44 2018 +0100
Libvirt release 4.9.0
* docs/news.xml: updated for release
Signed-off-by: Daniel Veillard <veillard@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2018-11-08 3:42 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-08 3:42 [libvirt test] 129491: regressions - FAIL osstest service owner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.