* [Xen-devel] [libvirt test] 144244: regressions - FAIL
@ 2019-11-22 15:42 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2019-11-22 15:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 144244 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144244/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 144233
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 144233
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 144233
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt 14 saverestore-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-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 d6064e2759a24e0802f363e3a810dc5a7d7ebb15
baseline version:
libvirt 5e939cea896fb3373a6f68f86e325c657429ed3d
Last test of basis 144233 2019-11-21 04:18:53 Z 1 days
Testing same since 144244 2019-11-22 04:18:48 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Erik Skultety <eskultet@redhat.com>
Jamie Strandboge <jamie@canonical.com>
Ján Tomko <jtomko@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 pass
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 pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-arm64-arm64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-arm64-arm64-libvirt-qcow2 fail
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 d6064e2759a24e0802f363e3a810dc5a7d7ebb15
Author: Erik Skultety <eskultet@redhat.com>
Date: Mon Nov 18 12:04:16 2019 +0100
libvirt-<module>: Check caller-provided buffers to be NULL with size > 0
Pre-Glib era which used malloc allowed the size of the client-side
buffers to be declared as 0, because malloc documents that it can either
return 0 or a unique pointer on 0 size allocations.
With glib this doesn't work anymore, because glib documents that for
such allocation requests NULL is always returned which results in an
error in our public API checks server-side.
This patch complements the fix in the RPC layer by explicitly erroring
out on the following combination of args used by our legacy APIs (their
moder equivalents don't suffer from this):
function(caller-allocated-array, size, ...) {
if (!caller-allocated-array && size > 0)
return error;
}
treating everything else as a valid input and potentially let that fail
on the server-side rather than client-side.
https://bugzilla.redhat.com/show_bug.cgi?id=1772842
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
commit bf2988235cf09c407f39791d446b1ecb99be6c51
Author: Erik Skultety <eskultet@redhat.com>
Date: Mon Nov 18 10:30:20 2019 +0100
rpc: gendispatch: Fix a couple of places adding trailing spaces
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
commit 5e067ba4e16350272e6a9c33940b56cc6eb9dd9a
Author: Ján Tomko <jtomko@redhat.com>
Date: Mon Nov 11 10:21:03 2019 +0100
conf: remove NULL check from virDomainQemuMonitorEventNew
The qemu_domain_monitor_event_msg struct in qemu_protocol.x
defines event as a nonnull_string and qemuMonitorJSONIOProcessEvent
also errors out on a non-NULL event.
Drop the check to fix the build with static analysis.
This essentially reverts commit d343e8203d248635f5e7a0d86dd077f74d49e3af
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
commit 7611a1ef002422c438c2e16fb2ce0d3034280253
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Tue Oct 22 12:13:41 2019 +0200
virt-aa-helper: testcase for shmem devices
Adding build time self tests for basic (deprecated), doorbell and plain mode.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit 36afd1a78ed8e13e33cdf954c6618c178ef777a1
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Thu Oct 17 12:48:10 2019 +0200
virt-aa-helper: add rules for shmem devices
Shared memory devices need qemu to be able to access certain paths
either for the shared memory directly (mostly ivshmem-plain) or for a
socket (mostly ivshmem-doorbell).
Add logic to virt-aa-helper to render those apparmor rules based
on the domain configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1761645
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit d53f4d02d032ec14391b5052ec165105dfc338b5
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Wed Oct 16 09:35:27 2019 +0200
apparmor: let AppArmorSetSecurityImageLabel append rules
There are currently broken use cases, e.g. snapshotting more than one disk at
once like:
$ virsh snapshot-create-as --domain eoan --disk-only --atomic
--diskspec vda,snapshot=no --diskspec vdb,snapshot=no
--diskspec vdc,file=/test/disk1.snapshot1.qcow,snapshot=external
--diskspec vdd,file=/test/disk2.snapshot1.qcow,snapshot=external
The command above will iterate from qemuDomainSnapshotCreateDiskActive and
eventually add /test/disk1.snapshot1.qcow first (appears in the rules)
to then later add /test/disk2.snapshot1.qcow and while doing so throwing
away the former rule causing it to fail.
All other calls to (re)load_profile already use append=true when adding
rules append=false is only used when restoring rules [1].
Fix this by letting AppArmorSetSecurityImageLabel use append=true as well.
Since this is removing a (unintentional) trigger to revoke all rules
appended so far we agreed on review to do some tests, but in the tests
no rules came back on:
- hot-plug
- hot-unplug
- snapshotting
Bugs:
https://bugs.launchpad.net/libvirt/+bug/1845506
https://bugzilla.redhat.com/show_bug.cgi?id=1746684
[1]: https://bugs.launchpad.net/libvirt/+bug/1845506/comments/13
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit 9714f270f1e94a4b46a066a623b2cd239fa70faf
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Wed Oct 16 09:32:52 2019 +0200
apparmor: refactor AppArmorSetSecurityImageLabel
A lot of the code in AppArmorSetSecurityImageLabel is a duplicate of
what is in reload_profile, this refactors AppArmorSetSecurityImageLabel
to use reload_profile instead.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit 70cf0af7bf34b6c0f3c009efc8366767dcd3c27d
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Wed Oct 16 09:15:14 2019 +0200
apparmor: drop useless call to get_profile_name
reload_profile calls get_profile_name for no particular gain, lets
remove that call. The string isn't used in that function later on
and not registered/passed anywhere.
It can only fail if it either can't allocate or if the
virDomainDefPtr would have no uuid set (which isn't allowed).
Thereby the only "check" it really provides is if it can allocate the
string to then free it again.
This was initially added in [1] when the code was still in
AppArmorRestoreSecurityImageLabel (later moved) and even back then had
no further effect than described above.
[1]: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/security/security_apparmor.c;h=16de0f26f41689e0c50481120d9f8a59ba1f4073;hb=bbaecd6a8f15345bc822ab4b79eb0955986bb2fd#l487
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit 9d38bce689557923c786ee4b36457830a167801c
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Wed Oct 16 08:47:36 2019 +0200
virt-aa-helper: clarify command line options
While only used internally from libvirt the options still are misleading
enough to cause issues every now and then.
Group modes, options and an adding extra file and extend the wording of
the latter which had the biggest lack of clarity.
Both add a file to the end of the rules, but one re-generates the
rules from XML and the other keeps the existing rules as-is not
considering the XML content.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.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-11-22 15:43 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-22 15:42 [Xen-devel] [libvirt test] 144244: 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.