<div dir="ltr">I think this is roughly the right approach - I've indeed already supportive on it in previous reviews/email discussions.<div><br></div><div>Conceptually, it is tantamount to adding an healing migration - which has the important characteristic of being idempotent.</div>
<div>One problem with it is that it won't work with offline migrations; "healing" migrations might be skipped when running in offline mode, but there won't be the possibility of having an offline script for fixing a DB, However this might be a non-issue once we assess how important it would be to support offline migrations.</div>
<div><br></div><div>From the pod discussion etherpad however it seems this solution was deemed too complex - and the consensus is to develop scripts which will need to be run upon upgrade; while I understand this will lead to an easier solution from the development perspective, it will also put the onus on the operator, which will need to perform ad-hoc upgrade operations.</div>
<div>Unless there are issues I'm not seeing at the moment, I think Anna is proving a few good points here:</div><div>1) DB healing can be performed within the migration framework</div><div>2) downgrades can be a simple no-op without breaking the consistency of the database</div>
<div><br></div><div>I would also like to add that we might still use this as a chance to clear our migration path completely, removing the configuration-dependent logic, and providing a new migration for downgrading from icehouse to havana; I don't think there is anymore a reason for keeping a path that stretches back to folsom.</div>
<div><br></div><div>Some pseudo-graphical details are available here: <a href="http://paste.openstack.org/show/81109/">http://paste.openstack.org/show/81109/</a></div><div><br></div><div>Regards,</div><div>Salvatore</div>
<div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 May 2014 09:13, Anna Kamyshnikova <span dir="ltr"><<a href="mailto:akamyshnikova@mirantis.com" target="_blank">akamyshnikova@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone!</div><div><br></div><div>Earlier topic of unconditional migrations was discussed  in emails by me and Salvatore. On summit there was a small meeting on which was discussed this topic and some others. I haven't participated in this meeting but member of my team Eugene was there instead of me and told me what was decided to do.</div>

<div><br></div><div>The idea is to create some methods that will check current table state:</div><div> - if it exists or not </div><div> -  if all necessary changes have been made or not. </div><div>(All changes are checked from the very beginning till Icehouse)</div>

<div><br></div><div>I was inspired of this idea and make some notes about that. They are shown there <a href="https://docs.google.com/document/d/10p6JKIQf_rymBuNeOywjHiv53cRTfz5kBg8LeUCeykI/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/10p6JKIQf_rymBuNeOywjHiv53cRTfz5kBg8LeUCeykI/edit?usp=sharing</a> and a test change that will show  how this is going to work <a href="https://review.openstack.org/93690" target="_blank">https://review.openstack.org/93690</a>. </div>

<div><br></div><div>The organizer of all this work is Henry Gessau. Now he is working on bp on this topic.</div><div><br></div><div>I look forward to any comments about my notes and my test changes.</div><div><br></div><div>

Regards,</div><div>Ann</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>