Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Jan Beulich <jbeulich@suse.com>]

On 01.08.2022 10:43, Julien Grall wrote:
> (+ Committers)
> 
> Hi Jan,
> 
> On 01/08/2022 09:36, Jan Beulich wrote:
>> On 29.07.2022 19:36, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/07/2022 07:22, Jan Beulich wrote:
>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>> branch xen-unstable-smoke
>>>>> xenbranch xen-unstable-smoke
>>>>> job build-amd64-libvirt
>>>>> testid libvirt-build
>>>>>
>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>
>>>>> *** Found and reproduced problem changeset ***
>>>>>
>>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>     Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>     Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>>>
>>>>>
>>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>     
>>>>>         libxl: Add support for Virtio disk configuration
>>>>
>>>> Just in case you didn't notice it: Something's wrong here. I didn't look
>>>> at the details at all. Please advise whether a fix will soon arrive or
>>>> whether we should revert for the time being.
>>>
>>> We had discussion on IRC about this today. This is an issue in libvirt
>>> rather than Xen. So I think a revert is not warrant here.
>>>
>>> Instead, it was suggested to force push because it is going to take some
>>> times to fix libvirt (see more below).
>>>
>>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even
>>> if this is accepted, our testing branch for libvirt is 2 years behind
>>> because they switched to Meson and Osstest has not been adapted to the
>>> new build system.
>>>
>>> Anthony kindly offered to update Osstest.
>>>
>>> Regarding force pushing, I am waiting for the Osstest result to confirm
>>> that only the libvirt tests are failing in staging (we already have the
>>> results for smoke). So my plan is to force push on Monday.
>>>
>>> Please let me know on Monday morning if you have some concerns with this
>>> approach.
>>
>> Actually I do - if we force push, the libvirt failure will stick, and
>> hence potential further regressions introduced there would not be noticed.
> 
> Well... We haven't had any push in libvirt for the past 2 years. So to 
> me it shows that nobody really care about the testing done. Therefore, I 
> don't see the problem if we don't spot further regressions.

I don't understand, or maybe I did express myself ambiguously: I'm not
talking about libvirt regressions (in their code base), but about changes
in our code regressing libvirt.

> If we don't force push, we have two solutions:
>    1) Revert Oleksandr's series
>    2) Leave it until we have Osstest fixed *and* Oleksandr's patch 
> reached libvirt.
> 
> The former is not an option for me, because Oleksandr's series is not at 
> fault. So this leave us to 2).
> 
> So what's your proposal?

It's still 1), no matter that I agree that Oleksandr's series is not
directly at fault.

Jan