RE: ISAR schroot mountpoints when running in container

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

> -----Original Message-----
> From: Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@siemens.com>
> Sent: Friday, July 1, 2022 5:08 PM
> To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>; Anton
> Mikanovich <amikan@ilbers.de>; isar-users@googlegroups.com
> Cc: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>; Bezdeka, Florian (T CED SES-
> DE) <florian.bezdeka@siemens.com>; ubely@ilbers.de; Schmidt, Adriaan (T CED
> SES-DE) <adriaan.schmidt@siemens.com>
> Subject: Re: ISAR schroot mountpoints when running in container
> 
> 
> 
> On 7/1/22 14:25, Moessbauer, Felix wrote:
> >> -----Original Message-----
> >> From: Anton Mikanovich <amikan@ilbers.de>
> >> Sent: Friday, July 1, 2022 2:09 PM
> >> To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>;
> >> isar- users@googlegroups.com
> >> Cc: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>; Bezdeka, Florian (T
> >> CED SES-
> >> DE) <florian.bezdeka@siemens.com>; ubely@ilbers.de; Schmidt, Adriaan
> >> (T CED
> >> SES-DE) <adriaan.schmidt@siemens.com>
> >> Subject: Re: ISAR schroot mountpoints when running in container
> >>
> >> 01.07.2022 14:30, Moessbauer, Felix wrote:
> >>> Required changes:
> >>>
> >>> In ISAR, we have to make the name of the Schroot folder more unique.
> >>> But as
> >> BB requires recipes to be deterministic (per-build), we have to
> >> inject the ID from the outside. This could happen either via
> >> local.conf or via an env-var. This env- var has to be provided by
> >> KAS, with an fallback in ISAR to use the PID of the bitbake process if not
> provided.
> >>>
> >>> A probably better strategy would be to get a per-bitbake invocation
> >>> constant
> >> UUID directly from Bitbake. Don't know if that already exists in BB.
> >>> Putting Adriaan in CC.
> >>>
> >>> Felix
> >>
> >> Hello, I've already proposed unique per-build ID generation in '[PATCH 2/6]
> base:
> >> Implement bitbake build ID'.
> >> Not sure it suits mentioned requirements, but can be good starting point.
> >
> > Just had a look at the patch. That should also work, but only if the date / time
> information is valid.
> > In some environments which are used to test reproducible builds, date / time
> might be fixed or redacted.
> >
> > I just sent out another approach that relies on an externally provided UUID.
> > Don't know which one is better.
> >
> > Felix
> >
> 
> 
> I did not find anything about it on the mailing list for sbuild but there are
> alternative to schroot available with the sbuild option --chroot-
> mode(schroot|sudo|autopkgtest|unshare)[1]. Did we test or discuss any of
> these modes?

I don't know if this has been discussed, but personally I tried multiple:

- schroot: That's what we currently use (base fs layer + overlay per sbuild invocation)
- sudo: similar to "sudo chroot ...". This suffers from the same problems as the previous ISAR implementation of the global buildchroot
- unshare: That's the best (IMO), but the feature-support heavily depends on the host-system. Issues are around missing /dev/pts, binfmt, broken pkg-autotest

Apart from that, two additional things have to be considered as well:
Mem usage: I personally run sbuild with unshare backend on a tmpfs, but depending on the package this requires gigabytes of RAM. In ISAR, the builds run in parallel, hence it does not really scale.
Disk usage: Having multiple full-blown chroots requires a lot of disk space. That's why the basic build infrastructure is put into the lower-dir of the overlayfs, while only the per-package build-dependencies are installed into the upper.

I hope this clarifies some of the design decisions, although they have not been made by me 😉

Felix

> 
> Also as we generate the schroot configuration can we disable the overlay
> usage[2]?

No, this is not possible (at least it is not implemented).

Felix

> 
> 
> [1]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmanpage
> s.debian.org%2Fbullseye%2Fsbuild%2Fsbuild.1.en.html&amp;data=05%7C01%7
> Cfelix.moessbauer%40siemens.com%7Cd2f153a84cc84974391408da5b73840c
> %7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63792284893296229
> 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=QoQWuM8
> dI2drew1QAKnLXSIFWmKA5baR1PuiZ%2FF73MQ%3D&amp;reserved=0
> [2]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmanpage
> s.debian.org%2Fbullseye%2Fschroot%2Fschroot.conf.5.en.html%23Filesystem_
> Union_chroot_options&amp;data=05%7C01%7Cfelix.moessbauer%40siemens.c
> om%7Cd2f153a84cc84974391408da5b73840c%7C38ae3bcd95794fd4addab42e
> 1495d55a%7C1%7C0%7C637922848932962298%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=1%2BcWUkyDvXEn20dGcIE5%2F0qn2AK4RA
> Dx%2F03QUUjh%2Fiw%3D&amp;reserved=0
> 
> Quirin