Data safety for our Fedora releases... :)

Giulio Fidente gfidente at redhat.com
Tue Jun 26 19:55:17 UTC 2012


On 06/20/2012 05:31 PM, Scott Seago wrote:
> 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).

one may also not want this to be an automated task, as potentially it is
quite risky

for products like spacewalk, the rpm/schema versioning approach remains
in place (there are schema upgrade scripts versioned using a specific
rpm) but the schema upgrades are not automated at all

a cronjob spawns an email alerting that some schema upgrades are needed
and the manual procedure expect the admin to shutdown and restart the
services

http://spacewalk.redhat.com/yum/1.7/Fedora/16/x86_64/spacewalk-schema-1.7.55-1.fc16.noarch.rpm
-- 
Giulio Fidente, gpg key id 08D733BA





More information about the aeolus-devel mailing list