Re: no more pullreq processing til February

[Daniel P . Berrangé]

On Thu, Jan 26, 2023 at 02:13:22PM +0000, Alex Bennée wrote:
> 
> Eldon Stegall <eldon-qemu@eldondev.com> writes:
> 
> > On Thu, Jan 26, 2023 at 01:22:32PM +0000, Peter Maydell wrote:
> >> Hi; we've run out of gitlab CI pipeline minutes for this month.
> >> This leaves us the choice of:
> >>  (a) don't process any more pullreqs til we get more minutes in Feb
> >>  (b) merge pullreqs blindly without CI testing
> >>  (c) buy more minutes
> >> 
> >> For the moment I propose to take option (a). My mail filter will
> >> continue to track pullreqs that get sent to the list, but I won't
> >> do anything with them.
> >> 
> >> If anybody has a better suggestion feel free :-)
> >
> > Would it be possible if (d) were to run self-hosted instances of the
> > runner? I am not sure how gitlab pricing works, but I believe on github
> > self-hosted runners are free.
> 
> Yes running more stuff on custom runners would be great (and also
> possibly not as slow as the heavily loaded shared runners).
> 
> > I have several baremetal machines colocated that I could dedicate to
> > execute these runs, dual processor xeons with a couple hundred gigs of
> > RAM. I would need approx 48 hours notice to initially provision the
> > machines. I would be happy to provide root credentials and work out IPMI
> > access if that becomes necessary.
> 
> I think we would need:
> 
>   - provisioning scripts in scripts/ci/setup (if existing not already
>     good enough)

The current approach for provisioning our private runners is highly
undesirable IMHO. We are installing the full set of build deps on
the host OS install, at time of provisioning the runner.

We should instead be provisioning the hosts exclusively to have
docker, and then use containers for the build + test environment,
so we don't need to have sysadmin intervention on the runners when
a merge request adds a build dep.

If we want to new private runners to replace the shared runners
transparently, then the use of docker is basically a must have.

>   - tweak to handle multiple runner instances (or more -j on the build)
>   - changes to .gitlab-ci.d/ so we can use those machines while keeping
>     ability to run on shared runners for those outside the project

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 :|