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

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 01/08/2022 09: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@xxxxxxxx>
>>>>>     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.
>
> 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?

This situation is unfortunate, but Oleksandr's series is not at fault,
and I don't think it is reasonable for libxl changes to be held hostage
like this.

The testing situation with libvirt is already bad.  I don't think a
force push is going to make it meaningfully worse.

~Andrew