I've started thinking how misago-docker should handle major updates where big changes happen, like when we want to update PostgreSQL from one major version to another.
I am wondering how much of a pain it would be for people if process was just "git clone new misago-docker version next to old one, then copy over the media directory and move the data using those commands"?
Maybe we could have an init script ask user "Do you want to import data from old misago-docker site?"
...it rather depends if you want to only support your docker compose build/install method, or if a more normal (generically more useful container) is a goal.
In an ideal world (my ideal world) any new version of the misago container should have an init script, that checks the current database schema, and upgrades if necessary (possible - it may be that jumping major versions is not supported)...and fails if not possible. A problem with this being rolling back (without backups) becomes problematic.
That way as misago evolves, upgrades are managed without direct action. Of course there's some devil in the detail around any such scheme (and if there are any changes to volume mounts over time).
This is unlikely to happen because support burden for such image is too much for me to carry. Suddenly the problem scope explodes from "I've got an error XYZ in misago-docker" into discussions like:
If this was so easy and doable, Discourse would've done it years ago. And yet, despite this being like no. 1 request on Discourses forums and them being millions of dollars funded startup hiring tens of devs, they still refuse to do it.
This all boils down to limitation of possibilities. misago-docker gives you a black box and "take it or leave" it deal. But when you try offering single image, suddenly a lot of people come asking how to do some things their way, because if image does X, why not make it also do X+1?
Support scope explodes from "I have an error XYZ in in predictable and reproductible setup" to "I am reinventing misago-docker and I have 2312 questions specific to my env, help me!" that is a nightmare for single person to take care of.
Basically this:
Interesting enough, after all those years community still couldn't settle on single community docker image for Discourse and multiple different solutions exist.
I do understand the rationale....but equally that's why I (and lots of other people) don't use discourse. The install it this way, or not at all, is not able to adapt to different hosting environments and circumstances.
...do upgrades of misago rely on running an upgrade script outside of docker, that changes the environment, and modifies the database when that is required? Or is that handles within the container? If it's handled within the container, there is no problem with any installation scheme/environment. Just updating the image, and restarting the container.
Misago's update is basically rebuilding docker against updated Misago's files and running two management commands:
python manage.py migrate: updates databasepython manage.py collectstatic: updates static directory's contentThings are getting hairy for updating PostgreSQL. Because you need to have both old and new PostgreSQL installed for pg_upgrade to work. Also major Misago releases will potentially be too much for Django's migrations feature. I guess this is an non-issue for people running off single docker/podman image with everything else supplemented from elsewhere ;)
Makes sense. So basically de-coupling the installation, from the postgres installation (as I require, and do) actually helps. The postgres maintenance is outside the scope of the misago install (postgres is maintained and upgraded as an external process or service).
This works better for me than a requirement for an all in one install, like discourse. It's also generally how most services that are migrating to the container model are working.
Another idea that comes to mind is using the branching model for versioning on misago-docker repo.
Currently main branch that people clone is master. We could make new main branch called v0-stable that has setup for stable Misago release, and v0-prerelease branch with misago pre-release code. After we release Misago 1.0, we can make the v1-stable and v1-prerelease branches and update main branch to v1-stable, so people doing git clone to setup new sites will default to new branch. Within minor versions we could either have separate v1-1-stable branches, or just stick to v1-stable branch
Update process would then be:
misago-docker version