| 19 Jun 2023 |
 @ronnypfannschmidt:matrix.org | In reply to @adis:blad.is
I think you'd want similar sandboxing guarantees in your migrations as you would at build time? cant exactly run a remote database migration without network | 12:44:13 |
 adisbladis | In reply to @ronnypfannschmidt:matrix.org
cant exactly run a remote database migration without network No, but tooling like pg_upgrade doesn't work on network connections | 12:44:46 |
| @ronnypfannschmidt:matrix.org | but application level schema migrations do for example | 12:45:07 |
| @ronnypfannschmidt:matrix.org | same goes for online migration using replication to avoid downtime | 12:45:38 |
| adisbladis | ^ This is also why dealing with migrations in a generalised manner isn't really that feasible. Everyone has very different operational constraints. | 12:47:50 |
| adisbladis | If we took the example from infinisil before where we'd print out migration steps.. I don't think that would realistically contain the steps for how to do zero downtime deploys. | 12:48:45 |
 growpotkin ( Alex Ameen ) | I'm not seeing how to review this. I think I already did | 20:24:43 |
 @piegames:matrix.org | Hm, then you can also give your approval in here and I'll start FCP | 20:51:55 |
 infinisil | growpotkin ( Alex Ameen ): Just review the RFC on GitHub again with an approve | 20:57:15 |
| infinisil | Like the standard way of reviewing PR's on GitHub | 20:57:42 |
 raitobezarius | 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) I wrote an issue on this | 21:18:52 |
| raitobezarius | And I am planning to do research on that in the next year | 21:19:11 |
| raitobezarius | (academical research) | 21:19:18 |
| raitobezarius | But like first thing first should be taking care of ensure-style options | 21:20:20 |
| raitobezarius | And making convergence works | 21:20:25 |
| raitobezarius | Once you have convergence, state migration is also a form of convergence | 21:20:38 |
| raitobezarius | With different performance properties (a lot of data, etc.) | 21:20:48 |
| raitobezarius | In reply to @adis:blad.is
^ This is also why dealing with migrations in a generalised manner isn't really that feasible. Everyone has very different operational constraints. Yes but deriving automatically the strategy based on composable parts seems possible IMHO | 21:21:32 |
| raitobezarius | In reply to @ronnypfannschmidt:matrix.org
right now there is no safe tooling for it, so its easy to mess up The stopgap solution for now is to have a global nixos module knob to disable automated migrations | 21:22:59 |
| raitobezarius | Or to enforce a RFC saying that all nixos modules should have an automatic migration flag | 21:23:22 |
| raitobezarius | During all my reviews, contributors usually don't want to bother and complain when I say this is a serious problem | 21:23:42 |
| 20 Jun 2023 |
| @ronnypfannschmidt:matrix.org | all modules either get safe migrations or need a unsafe flag per module in peoples config | 08:11:22 |
| @ronnypfannschmidt:matrix.org | then users can understand the quality levels by the unsafe migration flags they have to set | 08:11:59 |
| @piegames:matrix.org | What is a "safe" migration? How many upstreams even allow implementing this in the first place? | 08:12:48 |
| raitobezarius | safe migrations does not exist | 10:23:45 |
| raitobezarius | but unsafe migrations can always be made safe | 10:23:54 |
| raitobezarius | depend on how much resources you are ready to commit for it | 10:24:01 |
| @piegames:matrix.org | But how | 10:27:24 |
| raitobezarius | trivial safe migration algorithm: | 10:33:42 |
| raitobezarius | * trivial safe migration algorithm based on unsafe procedure M | 10:33:50 |
