>________________________________________ >From: Johannes Erdfelt [johan...@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.fainb...@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. > >JE
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. -S __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
