On 3/17/23 10:37, Laszlo Ersek wrote:
On 3/16/23 17:14, Andrey Drobyshev wrote:
> On 3/15/23 00:16, Richard W.M. Jones wrote:
>> On Tue, Mar 14, 2023 at 04:06:18PM +0200, Andrey Drobyshev wrote:
>>> Speaking of "make check": could you point out, for future
reference,
>>> which particular sub-target you're referring to here? I can see these:
>>> check-am, check-recursive, check-slow, check-TESTS, check-valgrind. And
>>> none of them seems to refer to checking docs integrity. Yet running
>>> entire "make check" might be quite time consuming.
>>
>> (FYI I'm on holiday at the moment, back 1st April)
>
> Hi Richard,
> Please enjoy your holiday, there's no urgency to answer this :)
>
>>
>> 'make check' runs the test suite and as Laszlo said is reasonably fast
>> (on my machine anyway!). Well, it should be around 5-15 mins. You
>> can add -j4 or -j`nproc` or similar to parallelise the tests.
>>
>> 'make check-valgrind' runs the same tests but with valgrind. This is
>> highly unlikely to affect this patch series which only touches OCaml
>> code.
>>
>> 'make check-slow' runs an extra set of tests that as you might guess
>> are quite slow. I wouldn't bother with this for a simple patch. I
>> usually run it before major releases.
>>
>> The other targets you mention are internally generated by automake.
>>
>> Then you can run single tests, eg:
>>
>> $ make check -C docs TESTS=" test-v2v-docs.sh "
>
> Thanks for the detailed overview. That is actually the answer to my
> original question: I was looking for a sub-target which would check the
> docs, and failed to see that instead there's a separate test for that
> purpose. And the reason for that is I tried running the suite as root
> and without "--keep-going" option, thus causing the recursive
"check"
> target to fail on tests/ before it gets to the docs/.
>
> This raises another question. If we run the "make check" suite
> properly, i.e. as non-root, then:
>
> 1. libvirt is being chosen as the default input method;
I don't understand this. "Input method" is set with the "-i"
option.
Did you mean "default libguestfs backend"?
Sorry, you're right, I seem to have missed the terms here. I meant the
libguestfs backend, which of course has nothing to do with v2v's input
method.
But even in that case, I don't understand. The default libguestfs
backend is supposed to be "direct".
If you have LIBGUESTFS_BACKEND permanently set to libvirt in your
environment, for various reasons, I'd suggest simply unsetting
LIBGUESTFS_BACKEND before running "make check".
No, I don't have this set in my environment. But here's the thing: in
RHEL, CentOS (and in other RHEL-like distros, I presume) libguestfs is
being built with the option "--with-default-backend=libvirt" set:
https://gitlab.com/redhat/centos-stream/rpms/libguestfs/-/blob/5089358fe5...
And if you don't put extra effort in linking your freshly built v2v with
libguestfs also built from source, but rather link it against the
libguestfs present in the system -- then the issue still exists and the
question remains.
I'm wondering how do you happen to avoid this issue, supposing that
you're also doing your development on a RHEL-like OS? Am I missing
something here? And having all that said: wouldn't it be beneficial and
more robust to explicitly set libguestfs backend when running the test
suite?
Laszlo
> 2. Due to this patch libvirt_uri is set to "qemu:///session":
>
https://listman.redhat.com/archives/libguestfs/2013-December/msg00085.html.
>
> Now if libvirtd is being run by root, qemu:///session won't work and
> we'll get "could not connect to libvirt (URI = qemu:///session)".
> That is exactly what I observe.
>
> If I follow the docs (
https://www.libguestfs.org/guestfs.3.html#backend)
> and explicitly set LIBGUESTFS_BACKEND, it gets better. I.e.
>
> LIBGUESTFS_BACKEND=libvirt:qemu:///system make check -jN
>
>
> But then there's the test test-v2v-o-libvirt.sh which connects to
> libvirtd not by the means of libguestfs, but rather invoking virsh
> directly, which causes:
>
> error: failed to connect to the hypervisor
> error: Cannot recv data: Connection reset by peer
>
> So the only way I'm able to successfully run the entire suite is this:
>
> LIBVIRT_DEFAULT_URI=qemu:///system
> LIBGUESTFS_BACKEND=libvirt:qemu:///system make check -jN
>
> My question is: is this how it's supposed to be?
>
>>
>> Note that some individual tests depend on the test-data dir having
>> been built first to build a bunch of phony guests:
>>
>> $ make -C test-data check
>>
>> (If you do 'make check' it will do the test-data dir first.)
>>
>> Rich.
>>
>
> Andrey
>