[openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

Chen, Wei D wei.d.chen at intel.com
Mon Apr 6 08:47:25 UTC 2015


I am the another one who like the idea, let SQLite goes where it belongs to, we have already knew there is couples of limitation in SQLite, actually, it hides some issues in some cases. As to functional testing, MySQL or other popular RDBMS is the better candidate.

 

+1

 

Best Regards,

Dave Chen

 

From: Rodrigo Duarte [mailto:rodrigodsousa at gmail.com] 
Sent: Sunday, April 05, 2015 2:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

 

yes please [2]

 

On Sat, Apr 4, 2015 at 1:07 PM, Raildo Mascena <raildom at gmail.com> wrote:

I totally agree, since this is not used in production and make the dev job more complicated.

@Henry If you want help with this, I would be glad to work with you to make this clean up.

 

On Sat, Apr 4, 2015 at 2:55 AM Henry Nash <henryn at linux.vnet.ibm.com> wrote:

Fully support this.  I, for one, volunteer to take on a lot of the work needed to clean up any our tests/environment to allow this to a happen. Hardly a month goes by without a fix having to be re-applied to our sql code to get round some problem that didn’t show up in original testing because SQLite is too promiscuous.

 

Henry

 

On 4 Apr 2015, at 01:55, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:

 

I am looking forward to the Liberty cycle and seeing the special casing we do for SQLite in our migrations (and elsewhere). My inclination is that we should (similar to the deprecation of eventlet) deprecate support for SQLite in Keystone. In Liberty we will have a full functional test suite that can (and will) be used to validate everything against much more real environments instead of in-process “eventlet-like” test-keystone-services; the “Restful test cases” will no longer be part of the standard unit tests (as they are functional testing). With this change I’m inclined to say SQLite (being the non-production usable DB) what it is we should look at dropping migration support for SQLite and the custom work-arounds.

 

Most deployers and developers (as far as I know) use devstack and MySQL or Postgres to really suss out DB interactions.

 

I am looking for feedback from the community on the general stance for SQLite, and more specifically the benefit (if any) of supporting it in Keystone.

 

-- 
Morgan Fainberg

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Rodrigo Duarte Sousa

Senior Software Engineer at Advanced OpenStack Brazil

Distributed Systems Laboratory
MSc in Computer Science

Federal University of Campina Grande
Campina Grande, PB - Brazil
http:// <http://lsd.ufcg.edu.br/%7Erodrigods> rodrigods.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150406/654a2f31/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6648 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150406/654a2f31/attachment.bin>


More information about the OpenStack-dev mailing list