Update nixpkgs.

nix store diff-closures

VirtualBox-GuestAdditions: 6.1.22-5.10.67 → 6.1.22-5.10.69
cpupower: 5.10.67 → 5.10.69
ena: 2.5.0-5.10.67 → 2.5.0-5.10.69
firmware-linux-nonfree: 2021-07-16 → 2021-09-19, +17864.4 KiB
initrd-linux: 5.10.67 → 5.10.69, -80.4 KiB
linux: 5.10.67, 5.10.67-modules → 5.10.69, 5.10.69-modules
nixos-system-monitoring: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-payments: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage001: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage002: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage003: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage004: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage005: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage1: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
nixos-system-storage2: 21.05.3367.fd8a7fd07da → 21.05.3468.92609f3d9bc
stage: -38.6 KiB
zfs-kernel: 2.0.6-5.10.67 → 2.0.6-5.10.69

It looks like this is essentially just a kernel bump.

ivank has put the fear of fresh Linux kernels into me (not that I was completely devoid of it before).

I asked NixOS matrix room about NixOS kernel QA and they told me it is basically:

• run the NixOS tests
• boot a system as a "smoke test"

They also pointed out NixOS kernels are pretty close to upstream (and then concluded from this observation that there's not likely to be a lot of NixOS-specific kernel problems).

Putting a fresh kernel onto staging seems okay to me. That's what staging is for. Even better would be if we could apply some load to staging after any upgrade... I suppose we'll get there.

I think it would be nice if we could say something like "kernels we put in production have run under load in staging for at least X days". For now production has no paying customers as users so a kernel goof has little negative impact so I don't mind deploying kernel updates as long as that's true.

I guess that means most of this comment is just thinking out loud for things we should do in the future. In that vein, I'd love it if the CI/CD system detected reboot-requiring changes and pointed them out to us somehow - and then actually rebooted systems on deploy (since if I just let CD deploy this to staging now it's basically a no-op even though it looks like we upgraded).

merged

mentioned in commit b350a35b

I filed #91

mentioned in merge request !228 (merged)