[Openstack-operators] [all] SQL Schema Downgrades: A Good Idea?
jlk at bluebox.net
Thu Jan 29 20:54:37 UTC 2015
On 1/29/15 11:26 AM, Morgan Fainberg wrote:
> I’m looking at the expectation that a downgrade is possible. Each time I
> look at the downgrades I feel that it doesn’t make sense to ever really
> perform a downgrade outside of a development environment. The potential
> for permanent loss of data / inconsistent data leads me to believe the
> downgrade is a flawed design. Input from the operators on real-world
> cases would be great to have.
> This is an operator specific set of questions related to a post I made
> to the OpenStack development mailing list:
In all the environments I've worked in, we have never relied on the
concept of a downgrade. Our policy was to always fail forward. All of
our upgrades have been done on live systems, with users actively
operating on them. We consider that any actions done from the point of
when an API service come back online are now part of the permanent
record and cannot be lost. To that end, any errors found are quickly
diagnosed, patched, and deployed to keep operations going.
It makes little sense to me to run into a problem with code, and then
trust that code to back out of what it had done (problematically in the
first place). In one environment I've worked in, we even had custom
downstream migrations involved, which CERTAINLY did not have backout
routines, and wouldn't have been tested to begin with. We do keep
backups of database content, from a disaster recovery POV, not from a
rollback POV. If we absolutely had to, we would do the restore from
previous backup, and attempt to mitigate differences in runtime
environments vs what the database reflects, but because of the
uncertainty that would be a last resort.
More information about the OpenStack-operators