| 10 Nov 2023 |
 raitobezarius | I think blocking on evaluation is the least way to piss people off | 20:48:07 |
| raitobezarius | Because it doesn't break your deployment | 20:48:12 |
| raitobezarius | It just make the upgrade painful | 20:48:21 |
| raitobezarius | Stable or unstable people are honestly to me the same people | 20:48:35 |
| raitobezarius | When I reason about which group to piss off | 20:48:40 |
| raitobezarius | I would like to piss off the people who are good at remediating from those situations | 20:48:47 |
| raitobezarius | Unfortunately, there's no channel called iamthexpertofanything | 20:48:59 |
 bendlas | we could try asking chatgpt 🙃 | 20:49:38 |
| raitobezarius | So in the end, we have to choose between evaluation errors or systemd runtime errors | 20:53:38 |
| raitobezarius | I mean, if we remove the stateVersion, we can make a systemd runtime error an evaluation error and just after the fix, it's a systemd runtime error | 20:53:59 |
| bendlas | In reply to @raitobezarius:matrix.org
I think blocking on evaluation is the least way to piss people off yes. unfortunately, we only seem to have the infrastructure for doing that for the variant of outright removing the option ...
I guess the principled way of doing that would be to add a kind of system-level "check phase", where before system activation, something would check compatibility ....
| 20:54:09 |
| bendlas | ... but it's also mighty late for attempting to squeeze a phase between eval and runtime ... 😅 | 20:55:23 |
| bendlas | more thoughts on this: https://github.com/NixOS/nixpkgs/issues/206467#issuecomment-1806441531 | 21:16:20 |
| raitobezarius | a check script could exist | 21:25:48 |
| raitobezarius | but it would probably end up just creating a systemd runtime failure | 21:25:54 |
| raitobezarius | I don't see how you do check script like NGINX check phase in a sandbox | 21:26:07 |
| raitobezarius | you'd need to leak the data inside the sandbox | 21:26:11 |
| raitobezarius | that's almost impossible | 21:26:15 |
| raitobezarius | doing a proper activation prefail would require a complete redesign of the stc | 21:26:26 |
| raitobezarius | in nixops, there's an issue to enable policy deployments in stc | 21:26:34 |
| raitobezarius | this was never adopted | 21:26:38 |
| * raitobezarius feel like he mentioned the policy deployments feature 30 times in his life | 21:26:46 |
| bendlas | feels like we could get started by replacing activation with something that runs the existing code through something like
[{action: "nixos.generation-symlink/set",
target: "/nix/store/<system>"},
{action: "nixos.legacy/activate-system",
variant: "boot",
target: "/nix/store/<system>"}]
| 21:39:51 |
| bendlas | if an action can also declare a pre-check, which is run before any action is attempted, that should already allow to run checks like this, without dragging state into the sandbox. | 21:47:04 |
| raitobezarius | anyone is welcome to work on that, but there's a lot of work involved into touching stc | 22:13:18 |
| bendlas | yeah, wanted to ask, what does stc stand for? 😅 | 22:13:52 |
| raitobezarius | switch-to-configuration.pl | 22:14:21 |
| raitobezarius | (click on the link) | 22:14:36 |
| bendlas | In reply to @raitobezarius:matrix.org
anyone is welcome to work on that, but there's a lot of work involved into touching stc right! hence: do the minimal thing, that would allow everyone to start chipping away at it ... | 22:15:49 |
| bendlas | ... while already addressing sore spots, like compatibility checks and migrations in /var | 22:17:28 |
