Re: artifact download for qtest

[Fabiano Rosas <farosas@suse.de>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Mon, Jun 08, 2026 at 04:13:02PM -0300, Fabiano Rosas wrote:
>> Thomas Huth <thuth@redhat.com> writes:
>> 
>> > On 30/05/2026 16.56, Ani Sinha wrote:
>> >> Hi,
>> >> 
>> >> I am trying to write a qtest for which I need an IGVM file. I have the
>> >> file, about 54 MiB in size.
>> >
>> > 54 MiB is quite big, I agree that we likely don't want to check that into 
>> > the main repository, especially if it is for a test only...
>> > (BTW, what's its compressed size?)
>> >
>> >> Instead of committing this IGVM binary
>> >> file with the test, I wanted to check if I can put it somewhere, say
>> >> in a gitlab repo and then make the test download it. This would be
>> >> similar to asset downloads for functional tests. No this test cannot
>> >> be a python functional test.  I am wondering if anyone has faced this
>> >> situation before and what the best way to solve this problem is.
>> >
>> > I'm not maintaining the qtests anymore, but I assume that there is no 
>> > interest in duplicating all the asset downloading logic there.
>> >
>> 
>> It would be nice if we could extract the existing code into a little
>> asset library that could be invoked from the other test frameworks.
>
> IMHO that isn't really practical, all the asset handling is in python.
> It'd be mad to re-implement that in C and then call it from python,
> and the C isn't really going to call the current python either....
>

What about a standalone downloader? I'm still thinking about reusing
more of the common operations between test frameworks. Is it feasible to
have a cmdline app that can be invoked by qtest and place artifacts in a
common place?

>> > What's the exact reason why you cannot do it as a functional test instead? 
>> > You could maybe also start the qemu binary there with "-accel qtest -qtest 
>> > ..." to fake a qtest environment - a little bit cumbersome, but certainly 
>> > doable, I think.
>
> ..if we didn't have the historical baggage already, then I'd that
> qtests should conceptually just be a subset of the functional
> tests. Writing them in python would be nicer than doing them in C.
>

But could we make _working_ with them in python be equivalent to C? I
agree it's nice to write tests in a higher level language, but python
specifically is a big pain when it comes to actually finding out why a
test is failing. And debugging is even worse.

The tradeoff is that unittest is clearly superior to glib as a test
runner. Having a more modern way of generating command-lines would be
nice too.

> The qtest service is integrated in QEMU, what's missing is
>
>  * the client side to talk the qtest protocol

python/qemu/machine/qtest.py?

>  * the various bus specific helper APIs
>
> I don't know how hard it would be to bootstrap the client side in
> python, but the general qtest protocol is 2000 lines of C, so
> probably more like 500 lines of python to replace it, plus whatever
> helpers you might want on top. Probably not terribly much work to
> get something useful kickstarted.
>
> NB, I am *not* sugggesting re-writing the actual existing tests,
> just make it possible to write new qtests in python.
>
> With regards,
> Daniel