| 10 Nov 2023 |
 bendlas | also, IMO it's called unstable for a reason, even if I don't like the sound of that sentiment ... | 20:34:31 |
 @gary.garyguo.net:lpc.events | * If you upgrade from PG14 to PG15, then you can keep using PG15 because PG15 changes the default permission on schema, but if a database is created before upgrade then it still keeps the old default permission. | 20:36:03 |
| bendlas | we have to also consider the social fallout: If you have to piss somebody of, and your only choice is "who?", then it's better to choose the group who's more likely to try to avoid a repetition of the experience by helping out in the future, instead of avoiding a repetition by stepping away ... | 20:38:34 |
| bendlas | but maybe there is a way to piss nobody off, let's give ourselves time until monday for a final decision, as raitobezarius said ... | 20:39:52 |
 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 |
