On 06/20/2012 10:51 AM, Justin Clift wrote:
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)
Yeah, that's the part about 'all new sprint releases go straight into
fedora' that's always worried me. Well destabilization in general, not
just db upgrades. That said, any actual development sprint is almost
certainly to include db migrations. I don't think I've seen one yet that
doesn't. Even bugfixes may include them, and may include other required
"upgrades" that aren't schema changes (i.e. 'rake dc:upgrade' vs
'rake
db:migrate'
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).
This is where we get in trouble with the current implementation. The
simplest way of attempting this would be to have the service 'start'
script upgrade if necessary. However, since we currently have two
processes (conductor itself and dbomatic), they'd both need to be
stopped to run db:migrate, since migrating a database with a live server
pointing to it will have unpredictable results, since it implies that
either before or after the migrate the code and db were out of sync,
potentially corrupting data.
As we discussed on irc, we may need to handle this with puppet somehow
-- since the service stop; upgrade; service restart will need to be
coordinated across services (potentially running on different boxes --
but that's a future extension).
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... ;)
How does it handle multiple db connections? or does it not have multiple
services that talks to the same database?
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
Scott