Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150404/c93a647a/attachment-0001.html>