Open Stack

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:
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html

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.

-- 
-jlk