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 <hen...@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.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 >
__________________________________________________________________________ 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