Missing upgrade paths

[Chi-Yu]

After running into #225, I came to the conclusion that the "upgrade paths" of this project aren't really well defined.

First of all, I completely forgot that syncserver needs to be updated via git instead of the system's package manager and therefore didn't update for 3 years until I ran into compatibility issues. Things would be a lot easier if this project actually had repositories for common Linux distributions such as Debian.

Then, the process via git pull --rebase tends to create merge conflicts in the syncserver.ini file which sometimes cannot be resolved automatically which leaves users with a broken configuration file until they resolve the conflicts manually. This could be avoided by hard-coding the "default" values elsewhere and actually tracking the "example" configuration as syncserver.ini.dist rather than syncserver.ini . That would automatically avoid those annoying merge conflicts since syncserver.ini is supposed to be customized and that doesn't work well when it's under version control.

SQL is another upgrade path issue by itself. I ran into #214 while trying to debug #225 because some tables were missing fields which I didn't know about and I still don't know whether my current database layout is up-to-date or not.

This project needs to define how to get from one database version to another without users having to risk breaking things by manually running ALTER TABLE statements on "production" databases without actually knowing what they are doing.

[rfk]

Thanks for this feedback. I agree the current upgrade experience is pretty rough, but unfortunately, we're not likely to be able to make many improvements to it from paid staff time.

There is some semi-related discussion happening in https://github.com/mozilla-services/syncserver/issues/179 about the future of this repo as a whole, and what the self-hosting experience will look like when our production system is fully migrated to the new Rust-based server infrastructure. The points you raise above are good things to factor in to that discussion.

[MichaIng]

Thanks for bringing this up, as this might become relevant for us as well. Basically for such, internal migration steps are nice. Possible "might" be to:

• define a database and config file version (stored in those) and add/remove/alter entries automatically on server start based on the difference
• or the whole list of migration steps could always run on start
• or it could be moved into an external command (or executable) to run manually after the instance has been upgraded.

But not sure whether investing time with this on the Python version makes sense, or better think about such for the new Rust implementations instead, if not yet the case.