> On Jan 29, 2015, at 2:27 PM, Monty Taylor <mord...@inaugust.com> wrote: > > On 01/29/2015 11:06 AM, Morgan Fainberg wrote: >> As a quick preface, today there is the assumption you can upgrade and >> downgrade your SQL Schema. For the most part we do our best to test all of >> this in our unit tests (do upgrades and downgrades land us in the same >> schema). What isn’t clearly addressed is that the concept of downgrade might >> be inherently flawed, especially when you’re talking about the data >> associated with the migration. 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. >> >> * If a migration fails in some spectacular way (that was not handled >> gracefully) is it possible to use the downgrade mechanic to “fix” it? More >> importantly, would you trust the data after that downgrade? >> * Once an upgrade has happened and new code is run (potentially making use >> of the new data structures), is it really safe to downgrade and lose that >> data without stepping back to a known consistent state? >> >> The other side of this coin is that it prevents us from collapsing data >> types in the stable store without hints to reverse the migration. >> >> I get the feeling that the reason we provide downward migrations today is >> because we have in the past. Due to the existence of these downward >> migrations the expectation is that they will work, and so we’re in a weird >> feedback-loop. >> >> I’d like to propose we stop setting the expectation that a downwards >> migration is a “good idea” or even something we should really support. >> Offering upwards-only migrations would also simplify the migrations in >> general. This downward migration path is also somewhat broken by the >> migration collapses performed in a number of projects (to limit the number >> of migrations that need to be updated when we change a key component such as >> oslo.db or SQL-Alchemy Migrate to Alembic). >> >> Are downward migrations really a good idea for us to support? Is this >> downward migration path a sane expectation? In the real world, would any one >> really trust the data after migrating downwards? > > I do not think downward migrations are a good idea. I think they are a > spectacularly bad idea that is essentially designed to get users into a > state where they are massively broken. > > Operators should fail forward or restore from backup. Giving them > downgrade scripts will imply that they work, which they probably will > not once actual data is involved.
+1 on disabling downgrades. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA __________________________________________________________________________ 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
