| 19 Jun 2023 |
 Ronny | 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 |
| Ronny | 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 |
| Ronny | 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 |
| Ronny | 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 |
