Re: Arm GDB buildbot workers

[Mark Wielaard <mark@klomp.org>]

Hi Christophe,

On Fri, Jul 08, 2022 at 12:11:13PM +0200, Christophe Lyon wrote:
> On 7/8/22 01:13, Mark Wielaard wrote:
> > OK. See the attached patch, 4 new workers each connected to a gdb CI
> > builder.
> 
> They are up and running! \o/
> I'll probably stop/start them several time to make adjustments like
> "admin name".

Great. In general that should be fine. It might interrupt a build, but
that should be retried when the worker comes backup.

> > Note that it might be helpful for keeping builds totally separate you
> > can use a worker for multiple builders. Depending on the number of
> I am not sure to follow?
> Why having a worker for multiple builders helps keeping the builds separate?

Sorry, I missed a word... "separate, but you" ...

> My plan was to have 1 container running a single worker/builder.
> That is 4 containers for 4 GDB "configs (distro x target)", 4 containers
> for 4 binutils "configs", X containers for X "configs".
> 
> But since these containers would use the same docker image, I think I'll
> need to adjust the worker_dir in bb-start.sh, otherwise for instance GDB
> and binutils containers/workers/builders would share the same dir, which
> won't work (they would compete for the twistd* files etc...)

Yes, each worker needs a separate worker dir. Which they normally have
in a container unless they share a volume. But I believe that is what
you are doing, have a shared bind mounted directory with the host.

You can of course start each container with separate --env WORKERNAME
environment variables, so you can share the image without hardcoding
everything.

> Do you instead recommend to have 1 (larger) container per distro x
> target, and run binutils/GDB/GCC builders inside this single container?

That is what I would recommend for a (virtual) machine. I think it
makes some sense for containers too, but maybe having separate
containers each with a dedicated worker/builder is smarter in that
case?

One advantage is that you can more easily control how many builds are
running at the same time. If the buildbot sees e.g. 8 different
workers it thinks they are all independent and it is fine to start 8
builds in parallel. While if you have one worker you can set
max_builds=4 and the buildbot will only start 4 builds at the same
time, queuing others.

On the other hand with separate containers per worker you can more
easily create "small" and "big" workers which handle completely
different builds (e.g. you might want a big dedicated gcc builder that
may use 32 vpcus at once, while for binutils builds you dedicate a
small container that only uses 4 vcpus at a time). We have ncpus vs
maxcpus for that, but it isn't as fine grained.

Cheers,

Mark