Data safety for our Fedora releases... :)

Javier Pena javier.pena at redhat.com
Wed Jun 20 15:27:47 UTC 2012


Hi all,

> 
> 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).
> 

RHEV-M is following a very similar approach. They have psql scripts covering each database schema change since the first release, and each new package applies the delta between schema versions. According to our local RHEV-M developer, Eli Mesika designed this schema, so you may want to contact him for more details.

Hope it helps,
Javier


> 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