|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 129491: regressions - FAIL
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@xxxxxxxxxx> John Ferlan <jferlan@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> ACKed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit ccc72d5cbdd85f66cb737134b3be40aac1df03ef Author: John Ferlan <jferlan@xxxxxxxxxx> 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@xxxxxxxxxx> ACKed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 67125e0d336ffca1c8dfeb058e3f7217d56c1642 Author: Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> Reviewed-by: John Ferlan <jferlan@xxxxxxxxxx> commit 29183778af488870ed09bb2239740f5d6cdba68b Author: John Ferlan <jferlan@xxxxxxxxxx> 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@xxxxxxxxxx> Reviewed-by: Erik Skultety <eskultet@xxxxxxxxxx> commit 4de4e4bc991158ea2a881d4729a668b2eb5fe83a Author: Michal Privoznik <mprivozn@xxxxxxxxxx> 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@xxxxxxxxxx> Reviewed-by: Erik Skultety <eskultet@xxxxxxxxxx> commit e7b7b617689ab6fff49b16b96aa417bf2382e79b Author: Michal Privoznik <mprivozn@xxxxxxxxxx> 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@xxxxxxxxxx> Reviewed-by: Erik Skultety <eskultet@xxxxxxxxxx> commit 18f90481cd47354cd834053b5bf12869f7afc8b6 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Nov 5 08:46:39 2018 +0100 Post-release version bump to 4.10.0 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 7a10a6a598ab4e8599c867060a7232a06c663e51 Author: Daniel Veillard <veillard@xxxxxxxxxx> 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@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |