Open Stack

Hi all,

We are working around adding support for sqlite into Alembic.
And we will switch to Alembic in I cycle in whole OpenStack I hope.
So don't touch sqlite.

Joe Gordon,

No we would like to merge it. Because at this moment we are able to run
unit test in Nova only against SQLite.
So it has critical importance for at least Nova, Glance and Cinder.


Best regards,
Boris Pavlovic

Mirantis Inc.






On Sat, Jul 20, 2013 at 12:48 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> Along these lines, OpenStack is now maintaining sqlachemy-migrate, and we
> have our first patch up for better SQLite support, taken from nova,
> https://review.openstack.org/#/c/37656/
>
> 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.
>
>
> On Wed, Jul 17, 2013 at 10:40 AM, Adam Young <ayoung at redhat.com> wrote:
>
>> On 07/16/2013 10:58 AM, Thomas Goirand wrote:
>>
>>> On 07/16/2013 03:55 PM, Michael Still wrote:
>>>
>>>> On Tue, Jul 16, 2013 at 4:17 PM, Thomas Goirand <zigo at debian.org>
>>>> wrote:
>>>>
>>>>  Could you explain a bit more what could be done to fix it in an easy
>>>>> way, even if it's not efficient? I understand that ALTER doesn't work
>>>>> well. Though would we have the possibility to just create a new
>>>>> temporary table with the correct fields, and copy the existing content
>>>>> in it, then rename the temp table so that it replaces the original one?
>>>>>
>>>> There are a bunch of nova migrations that already work that way...
>>>> Checkout the *sqlite* files in
>>>> nova/db/sqlalchemy/migrate_**repo/versions/
>>>>
>>> Why can't we do that with Keystone then? Is it too much work? It doesn't
>>> seem hard to do (just probably a bit annoying and boring ...). Does it
>>> represent too much work for the case of Keystone?
>>>
>>> Thomas
>>>
>>>
>>> ______________________________**_________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>> In general, yes, the SQlite migrations have eaten up far more time than
>> the benefit they provide.
>>
>> 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.
>>
>>
> Agreed, so lets change the default database away from SQLite everywhere
> and we can just override the default when needed for testing.
>
>
>
>> For any non-trivial deployent, we should encourage the use of Mysql or
>> Postgresql.  Migrations for these will be full supported.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130720/4d7c0991/attachment.html>