[openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

Sandy Walsh sandy.walsh at RACKSPACE.COM
Fri Jan 30 12:23:10 UTC 2015

>From: Johannes Erdfelt [johannes at erdfelt.com]
>Sent: Thursday, January 29, 2015 9:18 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues
>On Thu, Jan 29, 2015, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:
>> The concept that there is a utility that can (and in many cases
>> willfully) cause permanent, and in some cases irrevocable, data loss
>> from a simple command line interface sounds crazy when I try and
>> explain it to someone.
>> The more I work with the data stored in SQL, and the more I think we
>> should really recommend the tried-and-true best practices when trying
>> to revert from a migration: Restore your DB to a known good state.
>You mean like restoring from backup?
>Unless your code deploy fails before it has any chance of running, then
>you could have had new instances started or instances changed and then
>restoring from backups would lose data.
>If you meant another way of restoring your data, then there are
>some strategies that downgrades could employ that doesn't lose data,
>but there is nothing that can handle 100% of cases.
>All of that said, for the Rackspace Public Cloud, we have never rolled
>back our deploy. We have always rolled forward for any fixes we needed.
>From my perspective, I'd be fine with doing away with downgrades, but
>I'm not sure how to document that deployers should roll forward if they
>have any deploy problems.

Yep ... downgrades simply aren't practical with a SQL-schema based
solution. Too coarse-grained.

We'd have to move to a schema-less model, per-record versioning and
up-down conversion at the Nova Objects layer. Or, possibly introduce
more nodes that can deal with older versions. Either way, that's a big
hairy change.

The upgrade code is still required, so removing the downgrades (and
tests, if any) is a relatively small change to the code base.

The bigger issue is the anxiety the deployer will experience until a
patch lands.


More information about the OpenStack-dev mailing list