| 16 Jun 2023 |
 infinisil | But yeah sounds good then, let's wait for Alex though :) | 17:14:11 |
| 18 Jun 2023 |
|  toonn changed their profile picture. | 20:48:34 |
| 19 Jun 2023 |
| infinisil | growpotkin ( Alex Ameen ): Ping, we're still waiting for you as a shepherd to officially accept the new changes to RFC 140, please leave an accepting GitHub review | 08:19:52 |
| infinisil | * growpotkin ( Alex Ameen ): Ping, we're still waiting for you as a shepherd to officially accept the new changes to RFC 140, please leave an accepting GitHub review if all is good | 08:20:02 |
 @ronnypfannschmidt:matrix.org | is anyone aware of work on managing state versions and migration for components (like database server versions, database migration, data store migration)
i have had a number of times now where a upgrade that would ultimately fail at the end broke system state by runnign database migrations that the old versions couldnt use anymore (in particular nextcloud)
| 12:16:42 |
 @piegames:matrix.org | Uh, that's an interesting problem. | 12:19:23 |
 adisbladis | The usual answer is that you don't | 12:19:49 |
| infinisil | Definitely should be fixed at some point, I don't think anybody is actively working on that, but it's something that's been discussed a number of times throughout the years | 12:21:20 |
| adisbladis | The module is responsible for doing the right thing re stateVersion, which usually means to pin the version | 12:21:35 |
| infinisil | My 2 cents is that each service should have its own stateVersion-like option, so you can migrate each individually. | 12:21:53 |
| infinisil | And it should be a sequential number you increase whenever that specific service has a backwards incompatible change that could be migrated | 12:22:14 |
| adisbladis | In reply to @infinisil:matrix.org
My 2 cents is that each service should have its own stateVersion-like option, so you can migrate each individually. It's hard to create good ux around that | 12:22:28 |
| infinisil | Also, each number should be associated with documentation that specifies how to do the migration | 12:22:42 |
| infinisil | And integrated so that it gets printed automatically when needed | 12:23:00 |
| adisbladis | In reply to @ronnypfannschmidt:matrix.org
is anyone aware of work on managing state versions and migration for components (like database server versions, database migration, data store migration)
i have had a number of times now where a upgrade that would ultimately fail at the end broke system state by runnign database migrations that the old versions couldnt use anymore (in particular nextcloud) This sounds like a module bug that should be fixed | 12:23:24 |
| @ronnypfannschmidt:matrix.org | In reply to @adis:blad.is
This sounds like a module bug that should be fixed right now there is no safe tooling for it, so its easy to mess up | 12:23:45 |
| infinisil | I think it should be possible to create a stateVersions.<name> option that then each service sets | 12:23:54 |
| infinisil | E.g. nginx would set e.g. stateVersions.nginx = { version = 1; migrations = [ "Run this command: ..." ]; } | 12:25:09 |
| infinisil | * E.g. nginx would set stateVersions.nginx = { version = 1; migrations = [ "Run this command: ..." ]; } | 12:25:22 |
| adisbladis | In reply to @infinisil:matrix.org
E.g. nginx would set e.g. stateVersions.nginx = { version = 1; migrations = [ "Run this command: ..." ]; } I'm iffy on doing automated data migrations | 12:25:47 |
| infinisil | adisbladis: Not automated, you print the message to the user | 12:26:03 |
| @ronnypfannschmidt:matrix.org | and state versions are sometimes a problem in and of themselfes (like when you need/want to di a migration between major versions, or need a backup/restore step)
also sometimes migrations may or may not cooperate (for example well managed projects may have migrations that evetually enable a new feature, but also still enable older versions to run | 12:26:10 |
| infinisil | Yeah such integration should definitely give the user a choice and present all the interactions (like, backup first if you want to roll back afterwards, but you will lose data by doing so, etc.) | 12:27:05 |
| @ronnypfannschmidt:matrix.org | with the final key questions for a administrator/operator to deal with being things like - are migrations avaliable, what subset can i apply safely - how to i ensure backups/maintenance modes in case of breakage | 12:27:37 |
| adisbladis | In reply to @infinisil:matrix.org
adisbladis: Not automated, you print the message to the user Ahh, that's totally fine | 12:37:07 |
| adisbladis | It just struck me that impure derivations might be interesting for this use case | 12:37:51 |
| @ronnypfannschmidt:matrix.org | 2 important details wold be a) rejecting activation if the current state version isnt supported and 2. listing either avaliable state upgrades and/or hinting at a command to show them | 12:38:28 |
| @ronnypfannschmidt:matrix.org | i wouldnt consider it as job for a derivation per se - more like a "effect" that ensures activation is safe and/or enables upgrades of mutable state in a safe manner | 12:39:22 |
| adisbladis | I was thinking of it as a way to get localized tooling & ensure that you don't have impurities | 12:42:03 |
| adisbladis | I think you'd want similar sandboxing guarantees in your migrations as you would at build time? | 12:42:46 |
