| 15 Oct 2021 |
 @kraftnix:matrix.org | ^ sometimes your yubikey just decides to say something | 20:11:59 |
 David Arnold (blaggacao) | In reply to @timdeh:matrix.org
I wonder if this would help you David Arnold (blaggacao) on:
https://github.com/input-output-hk/nomad-driver-nspawn-nixos-container I'd rather have liked to see a move to OCI compliance. That would have made those custom runtime-adapters a whole class of non-ware. | 20:22:28 |
 @timdeh:matrix.org | yeah, I think systemd is the biggest blocker when it comes to OCI compliant NixOS containers unfortunately 😩 | 20:23:40 |
| David Arnold (blaggacao) | Why? | 20:23:51 |
| David Arnold (blaggacao) | systemd is a fair PID 1, no? | 20:24:27 |
| @timdeh:matrix.org | Well, have you found any OCI containers with systemd working inside them? Last I looked I couldn't find any examples 😅 | 20:24:33 |
| @kraftnix:matrix.org | I've done a few experiments with podman + building OCI containers with nix, but it is a bit nasty UX to debug when things don't work (+ rootless networking/containers was an issue at the time, may have changed) | 20:24:34 |
| David Arnold (blaggacao) | I mean, I would be surprised if systemd can't be pid 1 in a encapsulated environment. | 20:25:26 |
| David Arnold (blaggacao) | But systemd is a complete overhead. | 20:25:41 |
| David Arnold (blaggacao) | Sure. | 20:25:43 |
| David Arnold (blaggacao) | A runtime in a runtime 😎 | 20:25:54 |
| David Arnold (blaggacao) | But, if the goal is to make nixos container more interoperable... | 20:26:14 |
| @timdeh:matrix.org | I mean building an OCI container is simple with nix: pkgs.ociTools.buildContainer. It's putting an entire NixOS system inside one, complete with working service modules that's the real trick | 20:26:28 |
| @kraftnix:matrix.org | the systemd overhead is definitely one of the sadder parts of running nixos-containers / VM's on with a nixos hypervisor | 20:26:43 |
| @timdeh:matrix.org | I'm sure it is possible somehow, but I couldn't find an example of anyone who's figured it out yet | 20:26:54 |
| David Arnold (blaggacao) | OCI is just a file system contract + a manifest. | 20:27:16 |
| David Arnold (blaggacao) | And the runtime is an OCI compliemt runtime. | 20:27:27 |
| David Arnold (blaggacao) | What's run, that can be a single static binary. | 20:27:42 |
| David Arnold (blaggacao) | Or, systemd or s6 or ... | 20:27:53 |
| David Arnold (blaggacao) | systemd, a runtime itself, would try to compete with the runtime domain. | 20:28:32 |
| David Arnold (blaggacao) | So this layering is what makes it complex and the UX less than great. | 20:28:56 |
| @timdeh:matrix.org | yeah, I think that's why systemd made nspawn in the first place | 20:29:25 |
| @timdeh:matrix.org | I don't think it is an easy problem to solve | 20:29:31 |
| @timdeh:matrix.org | of course, maybe they made nspawn just to be jerks. Who knows 😅 | 20:29:54 |
| David Arnold (blaggacao) | Since there's an open standard, I beleive the latter is true. | 20:30:24 |
| @kraftnix:matrix.org | nspawn is alright (having used it for quite a while) the overhead is definitely less than running a full systemd-based OS | 20:30:49 |
| @timdeh:matrix.org | Well I just meant that when given the choice, it seems like the systemd devs roll their own solution rather than working with existing standards | 20:31:29 |
| @kraftnix:matrix.org | thats definitely true | 20:31:44 |
| @timdeh:matrix.org | so maybe they could have worked with OCI but chose not to | 20:31:44 |
| @kraftnix:matrix.org | the runtime overheads are actually fairly small (looking at my server atm), my bigger nspawn containers (like matrix, gitea, nextcloud) are using ~120-150MB RAM and ~15-20 extra processes, while a slim container (like openldap) seems fine with 20MB of RAM and 10 processes | 20:35:52 |
