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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
