On 1/29/21 3:53 PM, Daniel P. Berrangé wrote:
> On Fri, Jan 29, 2021 at 03:46:18PM +0100, Andrea Bolognani wrote:
> > On Fri, 2021-01-29 at 12:48 +0000, Daniel P. Berrangé wrote:
> > > On Wed, Jan 27, 2021 at 06:59:58PM +0100, Michal Privoznik wrote:
> > > > Since we've switched to meson our tests run with a timeout
(meson
> > > > uses 30 seconds as the default). However, not every machine that
> > > > builds libvirt is fast enough to run every test under 30 seconds
> > > > (each test binary has its own timeout, but still). For instance
> > > > when building a package for distro on a farm that's under load.
> > > > Or on a generally slow ARM hardware. While each developer can
> > > > tune their command line for building by adding
> > > > --timeout-multiplier=10, this is hard to do for aforementioned
> > > > build farms.
> > >
> > > I don't get why it is hard for build farms. Someone, somwhere
> > > is writing the script that invokes meson & ninja with some
> > > args. Why is it hard to add --timeout-multiplier=10 too ?
> > >
> > > > It's time to admit that not everybody has the latest, top shelf
> > > > CPU and increase the timeout.
> > >
> > > I'm not convinced we want to optimize for the slowest hardware
> > > we can find, especially when there's an easy option of setting
> > > --timeout-multiplier=10.
> >
> > It's not complicated to add the option, but the fact that Debian,
> > SUSE and now Fedora all need to specify a timeout multiplier hints to
> > the fact that perhaps the default timeout is just too small.
It's an arbitrary number that was chosen outside of libvirt devel community
and IIUC can change anytime meson devels please. So effectively the only
control we have is this --timeout-multiplier which is still not guaranteed
to yield correct results (e.g. if I now use multiplier of value 10 to allow
300s timeout but the default timeout is then changed to 20s, all of a sudfen
I have 200s timeout).
>
> AFAIK, Fedora hasn't set any timeout multiplier in our builds.
Only because Cole did not merge it, because I came up with idea for this
patch. Here's Cole's original patch:
https://www.redhat.com/archives/libvir-list/2021-January/msg00919.html
But okay, looks like we don't have an agreement here so I won't push this
patch. But Cole should still push his.
Oh that's not a real Fedora build - that's using COPR where s390 is
provided by QEMU TCG emulation. It is unsuprising that is slow as
treacle, and IMHO optimizing for that env is not desirable.
IOW, I'm not convinced we should merge Cole's either.
Regards,
Daniel
--
|: