Data safety for our Fedora releases... :)
Justin Clift
jclift at redhat.com
Wed Jun 20 14:51:43 UTC 2012
Hi all,
The good news (first)
*!*!*!*!*!*!*
We have working Aeolus rpm's are in official Fedora channels. (it's
been like this for a while) :)
The Challenge
*!*!*!*!*!*!*
How do we nicely update user data between Aeolus releases, without
losing anything or causing downtime?
For example, we have Aeolus 0.10.2 in Fedora 16.
When a new Aeolus version comes out (0.11.x, 0.12.x, 0.13.x, ...),
if it needs an upgraded the database schema, we can't let it break
existing installations.
As a first thought, this kind of presents two potential approaches:
a) If a new Aeolus version needs a db change, let's not push that
new Aeolus version to the Fedora official repos.
Example, Fedora 16 wouldn't get 0.11.0 (if 0.11.0 requires
db changes - no idea, it's just an example). :)
This doesn't stop us from pushing 0.11.0 to a new Fedora release
which has never had 0.10.2. (or rawhide, who's purpose is testing
new stuff)
b) We figure out some way of upgrading the database automatically.
So, Aeolus 0.10.2 in F16 example again. SysAdmin does "yum update",
maybe gets a new kernel at the same time... system reboots... and
Aeolus 0.11.0 is installed, running fine, and has automatically
updated the db as needed in the background. (no SysAdmin
intervention required).
There might be other approaches, but the two above stood out as most
obvious. a) sounds like the easiest, but it's probably not the
right move. Several months down the track from now, being stuck with
"ancient" versions of Aeolus releases in Fedora is unlikely to work for
us.
Piwik (for example) can do in place database upgrades, performed by the
running app itself. It's not going to be the only one whose approach
we could copy from... ;)
Does anyone have experience with this kind of thing with other db backed
web apps?
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
More information about the aeolus-devel
mailing list