From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Reinoud Zandijk" <reinoud@netbsd.org>,
"Ryo ONODERA" <ryoon@netbsd.org>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [RFC PATCH-for-8.2] .gitlab-ci.d/cirrus.yml: Promote NetBSD job as gating
Date: Thu, 9 Nov 2023 16:58:32 +0000 [thread overview]
Message-ID: <ZU0PuHyw8X8e/p0j@redhat.com> (raw)
In-Reply-To: <737f6fe5-cf3e-4fdd-b5d8-28f71a2fa9e6@linaro.org>
On Thu, Nov 09, 2023 at 04:35:56PM +0100, Philippe Mathieu-Daudé wrote:
> On 9/11/23 16:35, Philippe Mathieu-Daudé wrote:
> > This Cirrus-CI based job takes ~12min, similarly to macOS job.
> >
> > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > ---
> > Based-on: <20231109150900.91186-1-philmd@linaro.org>
> > "tests/vm/netbsd: Use Python v3.11"
> > ---
> > .gitlab-ci.d/cirrus.yml | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
> > index e7f1f83c2c..7b01acb104 100644
> > --- a/.gitlab-ci.d/cirrus.yml
> > +++ b/.gitlab-ci.d/cirrus.yml
> > @@ -94,8 +94,6 @@ aarch64-macos-12-base-build:
> > - cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml
> > variables:
> > QEMU_JOB_CIRRUS: 1
> > - QEMU_JOB_OPTIONAL: 1
> > -
> > x86-netbsd:
> > extends: .cirrus_kvm_job
> > @@ -110,3 +108,4 @@ x86-openbsd:
> > NAME: openbsd
> > CONFIGURE_ARGS: --target-list=i386-softmmu,riscv64-softmmu,mips64-softmmu
> > TEST_TARGETS: check
> > + QEMU_JOB_OPTIONAL: 1
>
> BTW OpenBSD works for me, but takes ~20min (similar to the FreeBSD job).
In the most recent pipeline FreeBSD too 22 mins, macOS 14 mins.
The key factor is that the Cirrus job needs to complete before the
GitLab job times out. We have a 1 hr 20 limit on GitLab jobs, and
Cirrus CI allows 2 jobs in parallel.
So in the worst case where the OpenBSD job was blocked until FreeBSD
job finished, we would be waiting about 45 mins for completion.
In the best case we would be waiting 36 mins.
Well technically the worst case would be no parallelization at all,
which is 70 mins serialized execution time, which is kinda close to
the 1hr20 limit. This does sometimes happen, but I don't know how
often.
Sometimes Cirrus CI can also delay the jobs starting for a while
due to lack of runners.
IOW, in normal times we could afford to enable all these jobs, but
if Cirrus CI is under heavy load we increase chance of timeouts.
I could have sworn our cirrus jobs were much slower in the past (around
the 40 min mark), as we had to cut down what we were running to avoid
frequent timeouts.
I'd say lets wait until this release is done though. Enable OpenBSD/NetBSD
when the new dev cycle opens up, so we can watch their stablility for a
bit, and not impact stability of the stable branch for this forthcoming
release.
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 :|
next prev parent reply other threads:[~2023-11-09 16:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 15:35 [RFC PATCH-for-8.2] .gitlab-ci.d/cirrus.yml: Promote NetBSD job as gating Philippe Mathieu-Daudé
2023-11-09 15:35 ` Philippe Mathieu-Daudé
2023-11-09 16:58 ` Daniel P. Berrangé [this message]
2023-11-09 17:15 ` Thomas Huth
2023-11-09 18:54 ` Philippe Mathieu-Daudé
2023-11-10 9:22 ` Daniel P. Berrangé
2023-11-10 9:30 ` Thomas Huth
2023-11-10 9:33 ` Daniel P. Berrangé
2023-11-10 21:12 ` Reinoud Zandijk
2023-11-11 17:33 ` Reinoud Zandijk
2023-11-13 6:53 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZU0PuHyw8X8e/p0j@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bleal@redhat.com \
--cc=kraxel@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=reinoud@netbsd.org \
--cc=ryoon@netbsd.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.