Evaluate the practical impact of having containerized Weblate
As per our meeting last week, we should evaluate the impact with these 2 criteria:
- lowering the maintenance cost
- non-root folks can help with the "backend" part
We said we wanted to do it twice:
- after the 1st post-containerization upgrade (probably only applicable to the maintenance cost criterion)
- after using it to do a few upgrades and folks had enough time to contribute to the platform without being root
Notes about 1st post-containerization upgrade (3.11 to 4.9)
For this upgrade the following steps had to be repeated 10 times (one for each intermediate version, as they can't be skipped):
settings.phpwith the new version.
- Fix any issues with our custom scripts, for example:
- Account for any changes in Weblate/Django API.
- Make sure hardcoded Python paths are correct.
- Check for important changes in the image (eg. changes in the base image).
- Bump the container image version.
- Run Puppet.
- Watch database migrations being applied in the container's log.
This is considerably less work than in the previous setup in which we had to, on top of the above, also handle Python module dependency resolution as well as versions and repositories pinning via Puppet-managed calls to
pip. The previous setup also didn't implement purging of old/unneeded Python packages, leaving old dependencies behind in the
/usr/local/lib/python3* directories. This could've been implemented but there were other pressing issues (such as the shutdown of the Pypi API which made automation even more difficult, the speed of Weblate releases, etc) and we decided to solve several issues at once with the move to a containerized service.
After some preparation, the actual upgrade process took around 5h, counting creation of backups (which i did a total of 3 times because of mistake and over-caution), doing all of the 10 upgrades and then checking that the system was working correctly and fixing small bits. I used a local copy of the Puppet code repo plus some simple tooling to automate some of the steps, because I wanted to be able to revert or restart the upgrade process without having to deal with the production repo during the process.
The next upgrade will need some adaptation to our custom scripts because there's a change in the base image which affects Python paths. Shouldn't be much work, though, and the dev/test server is serving as an important tool to make such work significantly smoother.