<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 29, 2013 at 3:48 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There were I think 5? 6? sessions on this general topic at the summit.<br>
<br>
<a href="https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations" target="_blank">https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations</a> is the<br>
session I coordinated; where Johannes & Mark Wash volunteered to put<br>
together the basic infrastructure for OpenStack going forward.<br>
<br>
We captured several key constraints:<br>
 * one deploy of new code : distributors cannot depend on lots of little steps<br>
  * <=5 seconds downtime with the database on each migration applied<br>
  * Stay HA during the entire period<br>
  * work with mysql 5.1 in the sense of can install/deploy etc.<br>
no-downtime configurations can require very recent versions of the DB<br>
(e.g. MySQL 5.5 and above)<br>
<br>
And a basic design:<br>
<br>
Basic design:<br>
 * Running foo db-sync will apply migrations in no-downtime fashion<br>
 * Migrations may be expand-contract, or in-place depending on<br>
anticipated data-size<br>
 * Abstraction layer for dealing with different HA configurations<br>
 * Code talking to the DB will know how to deal with all intermediary<br>
versions of the DB<br></blockquote><div><br></div><div style>If we need to support "all" intermediary versions forever, then schema migrations aren't exactly useful. So, how long do we need to maintain support for intermediary migrations?</div>
<div style><br></div><div style>  A -> B -> C</div><div style><br></div><div style>In other words, if patch A introduces intermediary schema support, patch B is a schema migration, and patch C removes legacy schema support, when can patch C land? Next milestone? Next release?</div>
<div style><br></div><div style>(A and B could be the same commit, but I separated them for illustration)</div><div style><br></div><div style>In my opinion, this makes the timing-based releases much more difficult, as it chokes the iteration process and makes swift's cycle much more appealing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 * Rollup migrations and cleanup legacy code on regular basis - e.g.<br>
once per release.<br>
<br>
IIRC glance was going to be the guinea pig, with code migrating from<br>
there to oslo once it starts to mature.<br>
<br>
Cheers,<br>
Rob<br>
<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<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>
</blockquote></div><br></div></div>