* [libvirt test] 132846: regressions - FAIL
@ 2019-02-05 14:57 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2019-02-05 14:57 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 132846 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132846/
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. 132776
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 132776
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 132776
test-arm64-arm64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt 14 saverestore-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-xsm 13 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
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-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
version targeted for testing:
libvirt 3bc3cca7bb43101730c94bc82762e5744420215a
baseline version:
libvirt 7c9dcfed5ae6d5874ea0e67e47a6871707b8446a
Last test of basis 132776 2019-02-03 13:45:39 Z 2 days
Testing same since 132846 2019-02-04 13:03:42 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrea Bolognani <abologna@redhat.com>
Cole Robinson <crobinso@redhat.com>
Peter Krempa <pkrempa@redhat.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 3bc3cca7bb43101730c94bc82762e5744420215a
Author: Peter Krempa <pkrempa@redhat.com>
Date: Thu Jan 31 15:37:53 2019 +0100
qemu: domain: Use 'raw' for 'volume' disks without format
Storage pools might want to specify format of the image when translating
the volume thus we can't add any default format when parsing the XML.
Add a explicit format when starting the VM and format is not present
neither by user specifying it nor by the storage pool translation
function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
commit 2f78ca803afb0be9091788cb3b115b480b9c812e
Author: Peter Krempa <pkrempa@redhat.com>
Date: Thu Oct 4 14:43:46 2018 +0200
qemu: domain: Assume 'raw' default storage format also for network storage
Post parse callback adds the 'raw' type only for local files. Remote
files can also have backing store (even local) so we should do this also
for network backed storage.
Note that virStorageFileGetMetadata always considers files with no type
as raw so we will not accidentally traverse the backing chain and allow
unexpected files being labelled with svirt labels.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
commit 6b618d2d5fd1dfd134a06dca4d2351ef94d8237b
Author: Peter Krempa <pkrempa@redhat.com>
Date: Mon Oct 8 15:30:36 2018 +0200
tests: qemu: Test network disks without format specified explicitly
Modify some existing tests of network-based disks to omit the storage
format specification.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
commit 6db0d033839807aec885e10b5a45748da016e261
Author: Peter Krempa <pkrempa@redhat.com>
Date: Fri Feb 1 17:54:46 2019 +0100
qemu: command: Don't skip 'readonly' and throttling info for empty drive
In commit f80eae8c2ae I was too agresive in removing properties of
-drive for empty drives. It turns out that qemu actually persists the
state of 'readonly' and the throttling information even for the empty
drive.
Removing 'readonly' thus made qemu open any subsequent images added via
the 'change' command as RW which was forbidden by selinux thanks to the
restrictive sVirt label for readonly media.
Fix this by formating the property again and bump the tests and leave a
note detailing why the rest of the properties needs to be skipped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
commit ae3955f486973b00bb5f2511d811f16b516923a5
Author: Andrea Bolognani <abologna@redhat.com>
Date: Mon Feb 4 09:22:31 2019 +0100
news: Fix typo
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
commit af36f8a641809556ac18dcc076f996033cb2385c
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Jan 20 12:23:29 2019 -0500
Require a semicolon for VIR_ONCE_GLOBAL_INIT calls
Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>). VIR_ONCE_GLOBAL_INIT is almost
exclusively called without an ending semicolon, but let's
standardize on using one like the other macros.
Add a dummy struct definition at the end of the macro, so
the compiler will require callers to add a semicolon.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit 8bec5488a60ece485309dc2955227b61bf1a2f27
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Jan 20 11:32:42 2019 -0500
Require a semicolon for VIR_LOG_INIT calls
Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>), and we have a mix of semicolon and
non-semicolon usage through the code. Let's standardize on using
a semicolon for VIR_LOG_INIT calls.
Drop the semicolon from the final statement of the macro, so
the compiler will require callers to add a semicolon.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit 6a4d938dd33b8a73409a36ee1bd766ee57c74a27
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Jan 20 11:30:15 2019 -0500
Require a semicolon for VIR_ENUM_IMPL calls
Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>), and we have a mix of semicolon and
non-semicolon usage through the code. Let's standardize on using
a semicolon for VIR_ENUM_IMPL calls.
Move the verify() statement to the end of the macro and drop
the semicolon, so the compiler will require callers to add a
semicolon.
While we are touching these call sites, standardize on putting
the closing parenth on its own line, as discussed here:
https://www.redhat.com/archives/libvir-list/2019-January/msg00750.html
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit 7662194bf32bee40b0dfc558344c37e5a76b12a6
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Jan 20 11:04:56 2019 -0500
Require a semicolon to VIR_ENUM_DECL calls
Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>), and we have a mix of semicolon and
non-semicolon usage through the code. Let's standardize on using
a semicolon for VIR_ENUM_DECL calls.
Drop the semicolon from the final statement of the macro, so
the compiler will require callers to add a semicolon.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@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:[~2019-02-05 14:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-05 14:57 [libvirt test] 132846: 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.