Hi, On 03/03/2021 11:39, Julian Maurice wrote:
I'm not too much concerned about the "push-test-release" process, but more about how we consistently make the code aware of the multiple possible database states. Surely we'd have to enforce a new set of rules for writing database updates. And we'd have to test these changes very carefully, since a tiny mistake could mean a loss of data. Of course you have backups, but DB rollback means downtime, right ?
Depends on the rollback I guess, some things you could probably revert without downtime. The possibility of loss of data due to programming error happens now as well and is no different.
So, that sounds like a lot of extra work for avoiding a few seconds of downtime (most of the time).
Not really sure it is more work than writing the current db upgrade procedures, maybe tiny bit, and a bit more if you want to be able to revert the DB upgrade as well (which is optional and I don't think we should even consider that for MVP implementation of this).
Also, what about template translations ? It takes some time to generate translated templates, and it can do weird things if the new code is used while using the old templates (or the old code with the new templates). Wouldn't that prevent zero-downtime upgrade ?
You redirect the traffic during upgrade to other nodes that are in working state and after the node being upgraded is ready to receive traffic you then can re-enable the traffic redirection there. Joonas -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto