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.fainb...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
