Re: [Libguestfs] [V2V PATCH v3 5/6] v2v, in-place: introduce --block-driver command line option

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?