This script is more widely used than just in our CI; wondering if we should have a separate script just for CI if this is needed

Testing should be possible on a laptop as well?

Right, but it's also used in the docker images on Docker Hub for example; https://github.com/docker-library/docker/blob/7db7eccb7b7507b1a6ba3ef81c6f37b16149cc55/Dockerfile-dind.template#L33-L38

Also not sure

• if we always want systemd to be used?
• if instead of cat-ing the unit file, we should just add a unit file to this repo, and COPY it into the container

Updated not to use systemd when systemd is not installed, but I think docker images on Docker Hub should fork the code.

if we always want systemd to be used?

I think we can use systemd always.

Also, even for rootful with cgroupfs driver, systemd might be useful for simplifying .integration-daemon-{start,stop} stuff.

if instead of cat-ing the unit file, we should just add a unit file to this repo, and COPY it into the container

No, the file needs to be autogenerated (for command args, workdir, and env vars)

Interestingly, this PR seems to have digged up some broken tests that hadn't been executed in CI.

[2020-02-10T21:34:56.998Z] --- FAIL: TestCgroupDriverSystemdMemoryLimit (1.76s)

[2020-02-10T21:34:56.998Z]     cgroupdriver_systemd_test.go:54: assertion failed: 67108864 (s.HostConfig.Memory int64) != 67108864 (mem int)

[2020-02-10T21:34:56.998Z] FAIL

[2020-02-10T21:34:56.998Z] 

[2020-02-10T21:34:56.998Z] === Failed

[2020-02-10T21:34:56.998Z] === FAIL: arm64.integration.system TestCgroupDriverSystemdMemoryLimit (1.76s)

[2020-02-10T21:34:56.998Z] === PAUSE TestCgroupDriverSystemdMemoryLimit

[2020-02-10T21:34:56.998Z] === CONT  TestCgroupDriverSystemdMemoryLimit

[2020-02-10T21:34:56.998Z]     cgroupdriver_systemd_test.go:54: assertion failed: 67108864 (s.HostConfig.Memory int64) != 67108864 (mem int)

@tianon PTAL?

I agree with the intent here (automated testing of more things via systemd, especially things that can't effectively be tested right now), but anything that runs systemd in a container, even more especially one that's typically run with --privileged, makes me very wary. I've seen way too many systems accidentally tanked thanks to systemd inside the container having some service someone forgot to disable that then tries to initialize already-initialized host devices (as an example), and causing the expected havoc.

could we add a variant just used for our CI, and keep the standard dind script as-is?

I like that idea, as long as the logistics work for actually using it 😅

Updated to split the script. PTAL.

@tianon PTAL?