<div dir="ltr"><div>Hi all, </div><div><br></div><div>We are working around adding support for sqlite into Alembic.<br></div><div>And we will switch to Alembic in I cycle in whole OpenStack I hope. </div><div>So don't touch sqlite. </div>
<div><br></div><div>Joe Gordon, </div><div><br></div><div>No we would like to merge it. Because at this moment we are able to run unit test in Nova only against SQLite.</div><div>So it has critical importance for at least Nova, Glance and Cinder. </div>
<div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div><div><br></div><div>Mirantis Inc.</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 Sat, Jul 20, 2013 at 12:48 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.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">Along these lines, OpenStack is now maintaining sqlachemy-migrate, and we have our first patch up for better SQLite support, taken from nova,  <a href="https://review.openstack.org/#/c/37656/" target="_blank">https://review.openstack.org/#/c/37656/</a><div>


<br></div><div>Do we want to go the direction of explicitly not supporting sqllite and not running migrations with it, like keystone.  If so we may not want the patch above to get merged.</div><div class="gmail_extra"><br>


<br><div class="gmail_quote"><div class="im">On Wed, Jul 17, 2013 at 10:40 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div>On 07/16/2013 10:58 AM, Thomas Goirand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/16/2013 03:55 PM, Michael Still wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 16, 2013 at 4:17 PM, Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you explain a bit more what could be done to fix it in an easy<br>
way, even if it's not efficient? I understand that ALTER doesn't work<br>
well. Though would we have the possibility to just create a new<br>
temporary table with the correct fields, and copy the existing content<br>
in it, then rename the temp table so that it replaces the original one?<br>
</blockquote>
There are a bunch of nova migrations that already work that way...<br>
Checkout the *sqlite* files in<br>
nova/db/sqlalchemy/migrate_<u></u>repo/versions/<br>
</blockquote>
Why can't we do that with Keystone then? Is it too much work? It doesn't<br>
seem hard to do (just probably a bit annoying and boring ...). Does it<br>
represent too much work for the case of Keystone?<br>
<br>
Thomas<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div>
In general, yes, the SQlite migrations have eaten up far more time than the benefit they provide.<br>
<br>
Sqlite migrations don't buy us much.  A live deployment should not be on sqlite.  It is OK to use it for testing, though.  As such, it should be possible to generate a sqlite scheme off the model the way that the unit tests do.  You just will not be able to migrate it forward:  later changes will require regenerating the database.<br>



<br></blockquote><div><br></div></div><div>Agreed, so lets change the default database away from SQLite everywhere and we can just override the default when needed for testing.</div><div class="im"><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


For any non-trivial deployent, we should encourage the use of Mysql or Postgresql.  Migrations for these will be full supported.<br>
<br>
>From a unit test perspective, we are going to disable the sqlite migration tests.  Users that need to perform testing of migrations should instead test them against both mysql and postgresql. the IBMers out there will also be responsible for keeping on top of the DB2 variations.  The [My/postgre]Sql migration tests will be run as part of the gate.<br>



<br>
The current crop of unit tests for the SQL backend use the module based approach to generate a sqlite database.  This approach is fine.  Sqlite, when run in memory, provides a very fast sanity check of our logic.  MySQL and PostgreSQL versions would take far, far too long to execute for everyday development. We will, however, make it possible to execute those body of unit tests against both postgresql and mysql as part of the gate.  Wer will also execute against the LDAP backend.  IN order to be able to perform that, however, we need to fix bunch of the tests so that they run at 100% first.<div>


<div><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div></div><br></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>