OpenProject updates are broken

It's that time of the year again, update time!

Following the best practices, I decided to update as much of my software as I could, to avoid any nasty CVEs or other vulnerabilities. So, the first thing that I did, was open my project management software of choice, OpenProject and registered a task for each thing I need to update:

There, I noticed that it would probably be nice to put it into a Kanban board of some sort, for that nice bit of visual feedback. Previously I actually used Kanboard for such purposes, because it's wonderfully lightweight, but since I'm already using OpenProject, I might as well check out the corresponding functionality there.

The need for an update

Sadly, my current version of OpenProject simply claims that it's a paid feature and I should upgrade my Community Edition to their Enterprise offering for something so basic:

However, that's not the story, if you look at their current documentation page on the topic, which says that the basic functionality is free:

What does that mean? They probably realized that that upsell is a bit too aggressive and decided to release a cut down version fo the boards for free. This also means that OpenProject is the first piece of software that I'll update!

The actual update didn't work

With containers, that should be pretty easy, right?

Just change the version from the old one, like so:

image: openproject/community:OLD_VERSION_NUMBER

to the new one, like so:

image: openproject/community:NEW_VERSION_NUMBER

And everything should work! Except that it doesn't:

The container fails, because the previous version of it included a PostgreSQL version that is no longer supported and it refuses to work with it. Curiously, it doesn't seem to work like PostgreSQL should, where you can just launch a newer container and it's going to do the due diligence to upgrade the data and whatnot from an older version.

This is precisely why "omnibus" installs, like GitLab offers and OpenProject also offers are risky and needlessly brittle.

Summary

While their docs have a page on how to manually update, it feels inferior to just having that piece of functionality be in a separate database container image and having the application at least make an attempt at working with whatever database it's given, outside of proven breakages when running an older DB.

Actually, right now I don't think I'll mess around with running the update process, because containers should be largely immutable and this simply signals a failure of keeping the runtimes separate from the data to a sufficient degree. Instead, I've added client certificate auth in front of the application to handle the security aspects until I get sufficiently bored and then will probably do a clean install in parallel and carry the data over to it. Who knows, maybe instead I'll try the upgrade first and see whether any interesting issues crop up.

Either way, don't be fooled by the seeming simplicity of an all-in-one install, in most cases it's not a good idea, same as serving your front end application from your back end container.