Cloudstack images are simply using cloud-init. They are not headless
as a user usually have access to a console. Otherwise, the difference
with Openstack are mostly handled by cloud-init.
This is still some minor issues. Notably, there is no non-root user.
Other cloud images usually come with a user named after the
distribution and with sudo. Would it make sense for NixOS?
Cloudstack gives the user the ability to change the password.
Cloud-init support for this is imperfect and the set-passwords module
should be declared as `- [set-passwords, always]` for this to work. I
don't know if there is an easy way to "patch" default cloud-init
configuration. However, without a non-root user, this is of no use.
Similarly, hostname is usually set through cloud-init using
`set_hostname` and `update_hostname` modules. While the patch to
declare nixos to cloud-init contains some code to set hostname, the
previously mentioned modules are not enabled.
It's a quick approximation to unblock unstable channels after #48116.
This commit isn't ideal, as I suspect most wayland users won't have
xserver.enable, so they will lose the icon cache in case they had gtk
in system path (otherwise they didn't get cache anyway).
I considered using environment.noXlibs, but the nixos tests installing
headless systems do *not* get that option, so we would still be pulling
gtk in many cases where it's clearly not desired. We need to design
this more carefully.
These days build systems are more robust w.r.t. to concurrency.
Most users will have at least two cores in their machines.
Therefore I suggest to increase the number of cores used for building.
fixes#50376
Imports the `journaldriver` module into the top-level NixOS module
list to make it usable without extra work.
This went unnoticed in #42134 (mostly because my setup imports modules
explicitly from pinned versions).
Fixes#50390
Based on reports X wouldn't start out of the box and seems OK now.
In case there are still some problems, we can improve later.
I checked that nixos.tests.virtualbox.* still succeed.
This will make the list much easier to re-use, eg. for `nixosTests`
The drawback is that this approaches makes the
```
nix-build release.nix -A tests.opensmtpd.x86_64-linux
```
command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs`
once for each architecture, instead of just having the hardcoded list of
tests that allowed to say “ok just evaluate for x86_64-linux”.
On the other hand, complete evaluation of `release.nix` should be much
faster because we no longer import `nixpkgs` for each test: testing with
the following command went from 30s to 18s, and that's just for a few
tests.
```
time nix-instantiate --eval --strict nixos/release.nix -A tests.nat
```
I initially wanted to test on the whole `release.nix`, but there are too
many broken tests and it takes too long to eval them all, especially
compared to the fact that the current implementation breaks some setup.
Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds
like an overall win.
