change kola to run unprivileged

[cgwalters]

Since coreos/coreos-assembler#190 changes our build process to run fully unprivileged, it'd align best if kola could run unprivileged; same as e.g. coreos-assembler run just directly runs qemu as an unprivileged user.

[ajeddeloh]

I think the issue is setting up the network namespaces for dnsmasq et. al, not qemu.

[bgilbert]

Also setting up the bridge. And, on CL, using loopback devices to mangle the OEM partition.

Platforms other than qemu don't need root.

[cgwalters]

qemu can do usermode networking as non-root. For example the Fedora standard-test-roles inventory/qcow2 program launches qemu and preps it for access via Ansible.

And, on CL, using loopback devices to mangle the OEM partition.

OK, not an issue for FCOS though - even if it was, we could use libguestfs to inject data rather than loopback mounts.

[dustymabe]

+1 - a cursory investigation of being able to do something like this might be useful, even if it's just to document the reasons root is needed.

[bgilbert]

qemu can do usermode networking as non-root.

kola is pretty fundamentally about testing clusters of nodes talking to each other. Usermode networking could potentially be made to work for at least some of those tests via port forwarding, but I think it'd be non-trivial.

[cgwalters]

I think we need "sanity checks" like "kernel doesn't emit a BUG_ON", "no systemd units fail", etc. that should be able to both run fully unprivileged and not require clustering. I really like having some basic testing integrated with the build pipeline.

We could have a different codebase or place for those than kola.

But - that code path isn't how we expect people to run in production (although there's an interesting intersection here with KubeVirt). We could then focus kola mainly for cloud providers (which again should be unprivileged with respect to the host/container) and not much on qemu.

[arithx]

Going to hack around at adding a second QEMU platform that doesn't include any of the LocalCluster functionality (which is what actually ends up requiring privileged access). Note that this new platform would likely not have the same feature set as the current QEMU platform and would likely have additional restrictions.

[arithx]

Closed in #968 with the addition of the qemu-unpriv platform.