+1 maintenance report (14/Aug - 18/Aug)

[Bryce Harrington]

On Mon, Aug 21, 2023 at 09:47:18AM -0700, Steve Langasek wrote:
> On Mon, Aug 21, 2023 at 10:16:31AM +0800, Shengjing Zhu wrote:
> > + golang-github-protonmail-go-crypto
> >   The error message says "out of memory". I can reproduce this on a VM with
> >   500M memory.
> >   It's because the testdata in TestSymmetricDecryptionArgon2 uses a large
> >   memory exponent parameter.
> >   It's same as https://github.com/ProtonMail/go-crypto/pull/178 (But this
> >   bug is only for 32bit arch, and is fixed in this package). 
> >   TestSymmetricDecryptionArgon2 is passed on 32bit arch, but only fails on
> >   arm64 and s390x.  Maybe the autopkgtest VM for these two architectures
> >   has less memory?  even less than armhf (I know it is lxd container
> >   instead VM, but not sure about the memory configurations).
> 
> >   LP: #2032145
> 
> The armhf lxd containers do not have hard partitioning of memory
> allocations, so *generally* tests on armhf will have more memory available
> than on other architectures.  But that memory is also shared across tests,
> so "noisy neighbor" effect is more of a problem.

Is there a technique for identifying when this may be the case, when
we're troubleshooting armhf-specific issues?

You know, it would be super useful if we had a handbook of architectures
for our autopkgtest infrastructure, that explains both the fundamental
differences between the architectures (e.g. cpu-specific uniquenesses)
and the implementational characteristics of how it's set up in Canonical
infrastructure (e.g. the memory configuration strategy with the armhf
lxd containers).  Does a doc like this already exist?

For new +1 maintainers this might help with some of the sense of
overwhelm one gets, but also even for experienced folks having itemized
lists of idiosyncrasies could help jog the memory.  (And as the
infrastructure evolves it could help communicate what's changed, and/or
identify more ways to improve...)

Bryce