That's nothing wrong with such small disk, and the default seems reasonable
enough.

external-disk-* parameters are fully tested, including it's special features
like keeping the image available even in case of dropping them from request
parameters.

See merge request nexedi/slapos!1173

See commit 37cf8a50.

Since
nexedi/slapos.core@a8917a3c
and slapos.core https://lab.nexedi.com/nexedi/slapos.core/tags/1.7.4 the
tap_ipv4_addr value is empty by default on the servers, especially test nodes.

To not rely on what is provided on the test environment simply mock the
configuration of the machine so that the test is able to prove profile
functionality.

The test does not require to download some enormous images, so provide small
empty qcow2 images, good enough to start the VM.

The problem has been introduced in 5da9c082
"kvm: Improve boot image url handling".

Note the internal usage of md5sum value as image name in the download config
creator.

pim-dm is a python3 only egg and re6st is a python2 only egg.

Deploy pim-dm egg inside a totally separated buildout in python3. 

See merge request nexedi/slapos!1161

See merge request !1170

Now the nat-rule-port always has the protocol name, see here:
https://lab.nexedi.com/nexedi/slapos/blob/9a886c4b0c6dd229564292eaa0ef2604fa857aea/software/kvm/instance-kvm.cfg.jinja2#L843

See merge request nexedi/slapos!1166

fixes CVE-2021-33503

fixes PVE-2022-47833

@tomo reports that parts/golang1.17/pkg/obj/go-build takes ~ 1GB which makes it
wasteful if we want to upload result of compilation to shacache.

It turns out we can drop that particular build cache completely, because it is
used only during the build and test of Go itself and its standard library. And
when Go is installed it will be another - "user" build cache - that will be
used to maintain and reuse build artifacts. For the reference: in SlapOS that
latter "user" build cache is located inside go.work/

-> Purge internal build cache after compilation is over.

Size of parts/golang1.17 before and after hereby patch:

before: 1.6G
after:  447M

See also related discussion in nexedi/slapos!929 (comment 128379)

/reviewed-by @tomo, @jerome
/reviewed-on nexedi/slapos!1169

New revision include a fix for waitdatabases which cause repman test instability.

See merge request !1163

Mostly to address the warning in the test that the request parameters
do not comply with schema.

software/{gitlab,nextcloud}: update options to new redis recipe

This changes software/nextcloud to be python3 and software/matomo no
longer need to explicitly use python3 anymore.

This is a fixup of 9a886c4b

This way we don't need to vendor python-redis (so we don't need to
update it for python3 support).

This also change the options in a backward incompatible way:
 - options are now kebab case ( server_bin -> server-bin )
 - a new cli-bin option holding the full path to redis-cli command
 is required to enable promise

This allow to view captured image from the test result log url (snapshot directory).