Re: [PATCH v2 07/12] qtest: bump prom-env-test timeout to 3 minutes

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jul 19, 2023 at 03:22:30PM +0200, Thomas Huth wrote:
> On 17/07/2023 20.28, Daniel P. Berrangé wrote:
> > The prom-env-test takes about 1 + 1/2 minutes in a --enable-debug
> > build. Bumping to 3 minutes will give more headroom.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >   tests/qtest/meson.build | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> > index c6da428dc5..095c98820e 100644
> > --- a/tests/qtest/meson.build
> > +++ b/tests/qtest/meson.build
> > @@ -5,6 +5,7 @@ slow_qtests = {
> >     'qom-test' : 900,
> >     'test-hmp' : 240,
> >     'pxe-test': 180,
> > +  'prom-env-test': 180,
> >   }
> >   qtests_generic = [
> 
> I tested your patches, and initially, everything looked good now. But this
> prom-env-test them reminded me that we run some additional tests in the
> "SPEED=slow" mode ... I guess we have to take these into consideration, too?
> 
> I now did a "configure --enable-debug" build and then ran:
> 
>  make -j$(nproc) check-qtest-ppc64 SPEED=slow
> 
> and indeed, this prom-env-test is now timing out there. Also the
> device-introspect-test was timing out in SPEED=slow mode. Should we bump the
> timeout for those, or could this maybe be handled via the TIMEOUT_MULTIPLIER
> in the final patch?

My goal was "no regressions" wrt current status for people working on
common development hardware. If people are using old, or modern low
performance hardware than a timeout multiplier would be expected.

IOW, for SPEED=slow, I think we need to "do the right thing" with
the default timeouts.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|