.gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 .gitlab-ci.d/cirrus.yml           | 37 -------------------------------
 .gitlab-ci.d/cirrus/kvm-build.yml | 31 --------------------------
 2 files changed, 68 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/kvm-build.yml

On Fri, 26 Apr 2024 at 12:38, Thomas Huth <thuth@redhat.com> wrote:
>
> During the past months, the netbsd and openbsd jobs in the Cirrus-CI
> were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
> from gitlab via the cirrus-run script was very fragile, and since the
> jobs were not run by default, it used to bitrot very fast.
>
> Now Cirrus-CI also introduce a limit on the amount of free CI minutes
> that you get there, so it is not appealing at all anymore to run
> these BSDs in this setup - it's better to run the checks locally via
> "make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
> remove these CI jobs now.

So what's the plan to keep BSD CI coverage? This seems
like a step backwards towards "the person handling the
pullreq merges has to do some local private ad-hoc testing
too" :-(

thanks
-- PMM

On 26/04/2024 14.30, Peter Maydell wrote:
> On Fri, 26 Apr 2024 at 12:38, Thomas Huth <thuth@redhat.com> wrote:
>>
>> During the past months, the netbsd and openbsd jobs in the Cirrus-CI
>> were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
>> from gitlab via the cirrus-run script was very fragile, and since the
>> jobs were not run by default, it used to bitrot very fast.
>>
>> Now Cirrus-CI also introduce a limit on the amount of free CI minutes
>> that you get there, so it is not appealing at all anymore to run
>> these BSDs in this setup - it's better to run the checks locally via
>> "make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
>> remove these CI jobs now.
> 
> So what's the plan to keep BSD CI coverage? This seems
> like a step backwards towards "the person handling the
> pullreq merges has to do some local private ad-hoc testing
> too" :-(

With regards to NetBSD and OpenBSD, this is not a step backward since these 
gitlab jobs were never run anyway (they could only be triggered manually, 
but hardly anybody did that AFAIK).

If we want to have proper support for those OSes, I think somebody would 
need to set up a custom runner on a beefy KVM-capable server somewhere where 
we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI 
runners still around? IIRC they were capable of running KVM ?

  Thomas

On Fri, Apr 26, 2024 at 02:47:20PM +0200, Thomas Huth wrote:
> With regards to NetBSD and OpenBSD, this is not a step backward since these 
> gitlab jobs were never run anyway (they could only be triggered manually, 
> but hardly anybody did that AFAIK).
> 
> If we want to have proper support for those OSes, I think somebody would 
> need to set up a custom runner on a beefy KVM-capable server somewhere where 
> we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI 
> runners still around? IIRC they were capable of running KVM ?

My datacenter had a power outage recently, so I disable my runner, and
haven't prioritized bringing it back up until now. I am glad to get this
going again, I'll look at it this weekend. 

It is a dedicated machine (R610 or Cisco UCS C220, I don't quite recall)
with I believe ~2X cores and 100+ GB memory. I hit a couple of minor
hurdles when CI started utilizing kubernetes runners, so one question I
had was whether I should install a lightweight kubernetes system and run
the gitlab kubernetes CI operator or the normal gitlab runner service. 

There should also be plenty of space to build *bsd VM's. Do pre-existing
upstream BSD images have an nocloud support so that we can build from a
stable updated base? Sorry I'm not super familiar with the BSD
ecosystems, but happy to try to fill in the gaps.

Thanks,
Eldon

On 26/04/2024 15.46, Eldon Stegall wrote:
> On Fri, Apr 26, 2024 at 02:47:20PM +0200, Thomas Huth wrote:
>> With regards to NetBSD and OpenBSD, this is not a step backward since these
>> gitlab jobs were never run anyway (they could only be triggered manually,
>> but hardly anybody did that AFAIK).
>>
>> If we want to have proper support for those OSes, I think somebody would
>> need to set up a custom runner on a beefy KVM-capable server somewhere where
>> we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI
>> runners still around? IIRC they were capable of running KVM ?
> 
> My datacenter had a power outage recently, so I disable my runner, and
> haven't prioritized bringing it back up until now. I am glad to get this
> going again, I'll look at it this weekend.

It's not for me to decide, but IMHO it would be a great possibility to run 
some additional KVM-based tests (like the vm-build-*bsd tests) in QEMU's CI!

> There should also be plenty of space to build *bsd VM's. Do pre-existing
> upstream BSD images have an nocloud support so that we can build from a
> stable updated base? Sorry I'm not super familiar with the BSD
> ecosystems, but happy to try to fill in the gaps.

QEMU's test suite comes with a handy way of doing tests on OpenBSD, NetBSD 
and FreeBSD: If you've got a KVM-capable Linux host, you just have to type 
"make vm-build-freebsd J=$(nproc)" to build and test the QEMU sources in a 
FreeBSD VM. It will automatically fetch and install a VM image for you.

  Thomas