Chris's Wiki :: blog/sysadmin/RequiredMigrationPain

How to get sysadmins to never use your software again

December 10, 2010

If your software keeps some sort of database or even just reads data files, and you want happy sysadmins, make it always be backwards compatible with the file formats of older versions. If you want moderately unhappy sysadmins, give it an automated migration process so that it reads the old format files and rewrites them in the new format.

(This makes sysadmins moderately unhappy because we can't back out of an attempted upgrade without restoring the old versions of the files, and as a corollary we can't switch back and forth between the two versions.)

Conversely, if you want to get sysadmins to never use your software again, make new versions of your program require active upgrade procedures, things that the sysadmins have to look up and do by hand (even if it is just running a program). You earn bonus points if part of the upgrade process is 'and check to make sure that nothing went wrong', and if it is a multi-step, multi-command thing that requires manual intervention and careful attention.

You might be tempted to say that any sysadmin who installs a new version of your program ought to also be willing to do some extra work along with it and besides, it's not that hard. There are two problems with this.

First, sysadmins often aren't actively choosing to upgrade to the new version of your program; instead we have the upgrade forced on us when we do things like upgrade our distribution. Second, we often aren't deeply experienced with your software and familiar with all of the fine details; instead we've taken a system package and slapped together something that worked. Then when your software turns an upgrade into a four alarm fire drill requiring major work to migrate a test version of live systems, test extensively, and then re-migrate the live system when the upgrade happens, sysadmins swear solemn vows to never ever be caught in the same trap again.

(Please don't suggest that we should ignore the version of your software that the distribution packages and instead compile from source. That too is a non-starter, for good reasons.)

On related news, Ubuntu 8.04 has MoinMoin version 1.5.8, Ubuntu 10.04 has MoinMoin version 1.9.2, and our support site currently uses MoinMoin. It is rather unlikely to do so in the future, because we are smart enough to only stub our toes once.

Comments on this page:

From 198.102.62.250 at 2010-12-10 10:56:17:

Used MoinMoin in the past and switched to Mediawiki (even with its PHP-encumbrances) for this very reason. Painful upgrade path. Sympathized with the Fedora packagers trying to make things smooth as possibe -- but they didn't even give it a try in EPEL.

-rvandolson

From 173.206.9.177 at 2010-12-10 13:43:50:

What good timing. I was going to install MoinMoin. Now I won't.

I poked around the moinmoin site looking for documentation. It is hard to find, and basically states to download and install MoinMoin to read the documentation. The only documents (online) for upgrading are written by other users. The windows centric upgrade from 1.8 to 1.9 states to delete and replace this file, and edit this other file. Sorry but no. Minor version upgrades should just work.

By trs80 at 2010-12-10 23:38:18:

Mmm, I'm interested to hear what you're going to use instead of MoinMoin; I didn't find the upgrade process that onerous. BTW, an excellent example of this (although moreso the latter part) is OpenLDAP, which has even caused Stockholm syndrome in the Debian maintainer.

From 69.97.111.101 at 2010-12-11 00:00:01:

This seems like a flaw in the packaging?

The problem (or feature) of MoinMoin and other web applications is that they are designed to be installed and run (both program and data files) from anywhere. Everyone's web server is configured differently. This precludes MoinMoin's upstream from attempting to do anything about it.

On Debian/Ubuntu, however, MoinMoin upgrade are (mostly) automated, provided you follow the packages convention (list of wikis in /etc/moin/farmconfig.py, and remaining configuration in /etc/moin/WikiName.py).

— Samat Jain

From 69.97.111.101 at 2010-12-11 00:08:16:

A note, if there was a legitimate fault of MoinMoin's upstream, it's that it released 1.6 as 1.6, instead of 2.0.

In MoinMoin 1.6, they switched Wiki syntaxes (from whatever was used before to a "standard" syntax called WikiCreole). This is as disruptive as it sounds—it made the data store completely backward incompatible, and forced a manual upgrade process.

Later MoinMoin releases (1.6 and later) are much easier to upgrade. Unfortunately, the data store is being rewritten in 2.0, so 1.x → 2.0 is going to be another headache.

By cks at 2010-12-13 11:20:08:

To answer trs80's question: right now we don't know what we're going to replace MoinMoin with. The leading candidate is probably ikiwiki, which seems sane, has an Ubuntu package, and can produce generated HTML if it comes down to it (so we can just throw away the 'wiki' bit and keep the generated HTML, or back-translate the generated HTML to a new wiki).

Written on 10 December 2010.

«	A small request for C programmers: no static locals

The danger of having system programmers around, illustrated