On Mon, Sep 07, 2020 at 10:03:36PM +0100, Richard Purdie wrote:

On Mon, 2020-09-07 at 16:55 -0400, Tom Rini wrote:

On Mon, Sep 07, 2020 at 02:59:41PM -0300, Otavio Salvador wrote:

Hello all,

Em seg., 7 de set. de 2020 às 13:14, Richard Purdie
<richard.purdie@...> escreveu:

...
Any thoughts from anyone on this?

I second this and at least at O.S. Systems we've been using Docker
containers to keep maintenance easier for old releases. I'd be
great
we could alleviate this and reduce its use as much as possible.

The CI builder maintenance is indeed a time-consuming task and as
easier it gets the easier is to convince people to set up them for
their uses and in the end, this helps to improve the quality of
submitted patches and reduces the maintenance effort as well.

Excuse what may be a dumb question, but why are we not just building
pyro for example in a Ubuntu 16.04 or centos7 (or anything else with
official containers available) ? Is the performance hit too much,
even with good volume management? And extend that for other branches
of course. But as we look at why people care about such old releases
(or, supporting a current release into the future) it seems like "our
build environment is a container / VM so we can support this on
modern HW" pops up.

The autobuilder is setup for speed so there aren't VMs involved, its
'baremetal'. Containers would be possible but at that point the kernel
isn't the distro kernel and you have permission issues with the qemu
networking for example.

Which issues do you run in to with qemu networking? I honestly don't
know if the U-Boot networking tests we run via qemu under Docker are
more or less complex than what you're running in to.

Speed is extremely important as we have about a 6 hour build test time
but a *massive* test range (e.g. all the gcc/glibc test suites on each
arch, build+boot test all the arches under qemu for sysvinit+systemd,
oe-selftest on each distro). I am already tearing my hair out trying to
maintain what we have and deal with the races, adding in containers
into the mix simply isn't something I can face.

We do have older distros in the cluster for a time, e.g. centos7 is
still there although we've replaced the OS on some of the original
centos7 workers as the hardware had disk failures so there aren't as
many of them as there were. Centos7 gives us problems trying to build
master.

The reason I was thinking about containers is that it should remove some
of what you have to face. Paul may or may not want to chime in on how
workable it ended up being for a particular customer, but leveraging
CROPS to setup build environment of a supported host and then running it
on whatever the available build hardware is, was good. It sounds like
part of the autobuilder problem is that it has to be a specific set of
hand-crafted machines and that in turn feels like we've lost the
thread, so to speak, about having a reproducible build system. 6 hours
even beats my U-Boot world before/after times, so I do get the dread of
"now it might take 5% longer, which is a very real more wallclock time.
But if it means more builders could be available as they're easy to spin
up, that could bring the overall time down.

So this plan is the best practical approach we can come up with to
allow us to be able to build older releases yet not change the
autobuilders too much and cause new sets of problems. I should have
mentioned this, I just assume people kind of know this, sorry.

Since I don't want to put even more on your plate, what kind of is the
reasonable test to try here? Or is it hard to say since it's not just
"MACHINE=qemux86-64 bitbake world" but also "run this and that and
something else" ?

--
Tom