| 20 Jun 2023 |
 raitobezarius | you rollback the failed upgrade's database | 10:38:44 |
| raitobezarius | not the others one | 10:38:47 |
| raitobezarius | except if you go further and you say that this group of 3 services needs to be coupled and then if you look at the systemd dependencies graph, you want to rollback every database | 10:39:19 |
| raitobezarius | (network dependencies are hard to discover but I don't think they're impossible to build) | 10:39:50 |
| raitobezarius | the way you take snapshots though is impl detail because you could use all kind of techniques which can be better depending on your exact situation | 10:40:14 |
| raitobezarius | system snapshot, filesystem-level snapshots, ZFS dataset-level snapshots, application-level snapshots, "backup/restore procedures" | 10:40:42 |
 Ronny | migrations as such need ot be kind of managed as involved service groups that may or may not share required rollbacks
for full safety you need service deployment granularity that enables migrations in steps where both older and newer versons currently avaliable can work with the data in question
maintenance modes for the applications that can happen independ of the code deployment are going to be important as well
so starting points like "having restorable backups" are definitively nice to have but applications themselfes also need some extras | 11:55:24 |
| Ronny | something fun and unique one could do with a system like nixos, is to have non gc roots of avaliable application versions that link to the state versions discoverable (like have a version of the old app, the new app and the migrate command, and the systemd service will pick the executable based on current state ) - classically this would be done with tagged container images | 11:57:10 |
| raitobezarius |
migrations as such need ot be kind of managed as involved service groups that may or may not share required rollbacks
yes but this is a metadata problem somewhat, right?
| 12:16:47 |
| raitobezarius |
for full safety you need service deployment granularity that enables migrations in steps where both older and newer versons currently avaliable can work with the data in question
if your app supports it, yes; if not, you don't need it, as long as you always know how to "rollback an app code" and "rollback an app data", this is the only thing you need and this can always be done if you know where all the state is and you have Nix semantics
| 12:17:43 |
| raitobezarius | (of course, caveats applies on app which relies on globally provided libraries such as GPU, but this is orthogonal to the whole discussion IMHO) | 12:18:01 |
| raitobezarius |
maintenance modes for the applications that can happen independ of the code deployment are going to be important as well
yes, maintenance mode is one of the low hanging fruit for those procedures, nixops had a PR which enabled many niceties on this, we discussed it again in nixos deployments but I don't think it went somewhere
| 12:18:34 |
| raitobezarius |
so starting points like "having restorable backups" are definitively nice to have but applications themselfes also need some extras
at least, they would prevent people losing all their bookmarks in nextcloud or losing all their docs in hedgedocs, because some contributors blindly believe that automatic rollback is fine because everyone is responsible and do backups (which is not totally true)
| 12:19:28 |
| raitobezarius |
something fun and unique one could do with a system like nixos, is to have non gc roots of avaliable application versions that link to the state versions discoverable (like have a version of the old app, the new app and the migrate command, and the systemd service will pick the executable based on current state ) - classically this would be done with tagged container images
this can already be achieved by manipulating nix profiles properly I believe
| 12:20:28 |
| raitobezarius | I'm not sure we would need to go further on that | 12:20:40 |
 @piegames:matrix.org | Given the stated intention and the fact that approving the PR in GitHub is more a formality than really required, I am going to start and announce FCP now (or at least today) | 12:37:36 |
 Growpotkin | I approve | 12:37:40 |
| @piegames:matrix.org | RFC 140 is now in FCP, Discourse announcement unfortunately cannot be made by me against prior knowledge | 12:56:30 |
| @piegames:matrix.org | * RFC 140 is now in FCP, Discourse announcement unfortunately cannot be made by me contrary to prior knowledge | 12:56:38 |
 infinisil | piegames: Well hexa just posted RFC 127 FCP into the Announcements category, not the RFC Announcements one: https://discourse.nixos.org/t/rfc-0127-fcp-nixpkgs-problem-infrastructure/29349 | 13:58:54 |
 hexa | I looked for a previous FCP announcement and it was posted there as well | 13:59:18 |
| hexa | I had no idea the other category existed | 13:59:25 |
| hexa | nor could I have posted to it | 13:59:32 |
| infinisil | Yeah, we previously ran into this same problem | 13:59:50 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: Well hexa just posted RFC 127 FCP into the Announcements category, not the RFC Announcements one: https://discourse.nixos.org/t/rfc-0127-fcp-nixpkgs-problem-infrastructure/29349 Oh wow, I didn't even notice | 14:00:03 |
| infinisil | What we could do is post a comment in https://discourse.nixos.org/c/announcements/rfc-announcements/22 | 14:00:07 |
| infinisil | I mean https://discourse.nixos.org/t/rfc-0140-fcp-simple-package-paths/28589 | 14:00:16 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
What we could do is post a comment in https://discourse.nixos.org/c/announcements/rfc-announcements/22 I tried, and nope | 14:00:24 |
| infinisil | Oh wow you cannot even reply to a topic posted there | 14:00:44 |
| hexa | contact ryantm | 14:00:48 |
