<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">From an operator perspective I wanted to get input on the SQL Schema Downgrades.<div class=""><br class=""></div><div class="">Today most projects (all?) provide a way to downgrade the SQL Schemas after you’ve upgraded. Example would be moving from Juno to Kilo and then back to Juno. There are some odd concepts when handling a SQL migration downgrade specifically around the state of the data. A downgrade, in many cases, causes permanent and irrevocable data loss. When phrased like that (and dusting off my deployer/operator hat) I would be hesitant to run a downgrade in any production, stagings, or even QA environment.</div><div class=""><br class=""></div><div class="">In light of what a downgrade actually means I would like to get the views of the operators on SQL Migration Downgrades:</div><div class=""><br class=""></div><div class="">1) Would you actually perform a programatic downgrade via the cli tools or would you just do a restore-to-last-known-good-before-upgrade (e.g. from a DB dump)?</div><div class="">2) Would you trust the data after a programatic downgrade or would the data only really be trustworthy if from a restore? Specifically the new code *could* be relying on new data structures and a downgrade could result in weird states of services.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">This is an operator specific set of questions related to a post I made to the OpenStack development mailing list: <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html" class="">http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html</a></div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Morgan </div></body></html>