Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
Quoting Morgan Fainberg (2015-04-04 02:55:59) 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 +1 __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On 4/6/15 2:52 PM, Morgan Fainberg wrote: On Apr 6, 2015, at 11:41, Mike Bayer mba...@redhat.com mailto:mba...@redhat.com wrote: On 4/6/15 12:49 PM, David Stanek wrote: Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. is that because you'd prefer that the unit tests were more isolated, or just that an external service is being used? I've done some work with extensive mocking of SQL databases; specifically mocking at the ORM level. It is nice when you get it to run, but it's also a much bigger job to write fine-grained mocks like that, the mocks can be brittle in relation to the code they're targeting, and you also need to come up with some solution to actually functional test your database access code. I tend to think that having a mysqld service running is the lesser of two evils and you get a lot more code coverage by going all the way out to the DB. What David is specifically referencing is that we want our functional tests to only require direct API access. There is almost no reason to need access to the DB backend. We have many ways to perform isolation where needed (tempest does a lot of this today). The goal is to allow the functional test suite to run against any keystone deployment (be agnostic to db, non-db, etc driver used). This makes environment setup a separate concern the tests don't need to be involved in/aware of. It makes our functional tests more useful for validating a driver or configuration passes muster. ah. for sure. I would think functional tests could run against a backend that was entirely mock / file-based. If there are legitimately cases we need to test a specific db function in isolation we will make specific efforts to support it. Those are apt to be the exception to the rule. --Morgan Sent via mobile On Mon, Apr 6, 2015, 12:42 Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: On Apr 6, 2015, at 09:20, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On Apr 6, 2015, at 11:41, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:49 PM, David Stanek wrote: Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. is that because you'd prefer that the unit tests were more isolated, or just that an external service is being used? I've done some work with extensive mocking of SQL databases; specifically mocking at the ORM level. It is nice when you get it to run, but it's also a much bigger job to write fine-grained mocks like that, the mocks can be brittle in relation to the code they're targeting, and you also need to come up with some solution to actually functional test your database access code. I tend to think that having a mysqld service running is the lesser of two evils and you get a lot more code coverage by going all the way out to the DB. What David is specifically referencing is that we want our functional tests to only require direct API access. There is almost no reason to need access to the DB backend. We have many ways to perform isolation where needed (tempest does a lot of this today). The goal is to allow the functional test suite to run against any keystone deployment (be agnostic to db, non-db, etc driver used). This makes environment setup a separate concern the tests don't need to be involved in/aware of. It makes our functional tests more useful for validating a driver or configuration passes muster. If there are legitimately cases we need to test a specific db function in isolation we will make specific efforts to support it. Those are apt to be the exception to the rule. --Morgan Sent via mobile On Mon, Apr 6, 2015, 12:42 Morgan Fainberg morgan.fainb...@gmail.com wrote: On Apr 6, 2015, at 09:20, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other backends as well such as Postgresql. The reasons outlined by both Clint and Mike are why we won't be attempting this until we are happy with our functional test suite. But once we are happy dropping SQLite is on the table. The way I see it the functional tests should be performed against a real keystone server, even if it is one spun up for testing specifically. Per test db
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On 4/6/15 12:49 PM, David Stanek wrote: Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. is that because you'd prefer that the unit tests were more isolated, or just that an external service is being used? I've done some work with extensive mocking of SQL databases; specifically mocking at the ORM level. It is nice when you get it to run, but it's also a much bigger job to write fine-grained mocks like that, the mocks can be brittle in relation to the code they're targeting, and you also need to come up with some solution to actually functional test your database access code. I tend to think that having a mysqld service running is the lesser of two evils and you get a lot more code coverage by going all the way out to the DB. On Mon, Apr 6, 2015, 12:42 Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: On Apr 6, 2015, at 09:20, Mike Bayer mba...@redhat.com mailto:mba...@redhat.com wrote: On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other backends as well such as Postgresql. The reasons outlined by both Clint and Mike are why we won't be attempting this until we are happy with our functional test suite. But once we are happy dropping SQLite is on the table. The way I see it the functional tests should be performed against a real keystone server, even if it is one spun up for testing specifically. Per test db creation / other such stuff will be part of that discussion. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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:
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On Mon, Apr 6, 2015 at 2:41 PM, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:49 PM, David Stanek wrote: Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. is that because you'd prefer that the unit tests were more isolated, or just that an external service is being used? There are two types of testing that I'm interested in really promoting in Keystone. I want to see functional tests that only use the published APIs to trigger and observe behavior. I also want to see unit tests that are small, fast and that test the business logic of the system. I started working[1] on functional testing in the Kilo cycle. The spec[2] talks about standing up Keystone in different configurations (MySQL, LDAP, Federated, etc.) and then running a set of tests against that instance. This will allow us the test any backend we want and confirm it works the way we expect Keystone to work. On the other hand I want the unit tests to be smaller and faster. The job of the unit tests should be to test small isolated bits of code and help guide/evaluate the code design. Except to test the SQL backends I don't see a need for using a database and even then I'd like to get by without it. I've done some work with extensive mocking of SQL databases; specifically mocking at the ORM level. It is nice when you get it to run, but it's also a much bigger job to write fine-grained mocks like that, the mocks can be brittle in relation to the code they're targeting, and you also need to come up with some solution to actually functional test your database access code. I tend to think that having a mysqld service running is the lesser of two evils and you get a lot more code coverage by going all the way out to the DB. The simplicity of the Keystone design is actually very good for dealing with this (controller - manager - backend). Since backends are where the actually query work happens we can easily provide a fake for each subsystem that we want to test. This would allow us the test the business rules in the manager without a database. The reason that is good is that we'd probably be better off requiring LDAP (if anything) for some of the subsystems since that is what they are typically configured to use. I would rather just leave that level of detail to the functional tests. 1. https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:functonal-testing,n,z 2. https://review.openstack.org/#/c/153300/l -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
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:rodrigodso...@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 rail...@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 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 -- 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 smime.p7s Description: S/MIME cryptographic signature __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On Apr 6, 2015, at 09:20, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other backends as well such as Postgresql. The reasons outlined by both Clint and Mike are why we won't be attempting this until we are happy with our functional test suite. But once we are happy dropping SQLite is on the table. The way I see it the functional tests should be performed against a real keystone server, even if it is one spun up for testing specifically. Per test db creation / other such stuff will be part of that discussion. __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other backends as well such as Postgresql. __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. On Mon, Apr 6, 2015, 12:42 Morgan Fainberg morgan.fainb...@gmail.com wrote: On Apr 6, 2015, at 09:20, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:06 PM, Clint Byrum wrote: Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. The standard approach here is that tests based on the oslo.db approach by default connect using a username openstack_citest on localhost, which is then used to create databases of random names. If you base your database tests on oslo.db, you get that right now. This username/host/etc is also configurable through environment variables. I don't see how my.cnf is involved in this nor how it would impact someone's keystone database, unless we're talking about tests that happen to load down and/or crash the whole database server. spinning up a whole mysqld seems really heavy-handed and unnecessary. Not to mention the tests run on other backends as well such as Postgresql. The reasons outlined by both Clint and Mike are why we won't be attempting this until we are happy with our functional test suite. But once we are happy dropping SQLite is on the table. The way I see it the functional tests should be performed against a real keystone server, even if it is one spun up for testing specifically. Per test db creation / other such stuff will be part of that discussion. __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700: On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. Please please please be careful with that and make sure the database name is _always_ random in tests... or even better, write a fixture to spin up a mysqld inside a private tempdir. That would be a really cool thing for oslo.db to provide actually. I'm just thinking some poor sap runs the test suite with the wrong .my.cnf in the wrong place and poof there went keystone's db. __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
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
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 rail...@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 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 -- 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://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On Saturday 04 April 2015 03:55:59 Morgan Fainberg 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. +1. Drop it and clean up tons of code used for support of sqlite only. Doing tests with mysql is as easy, as with sqlite (mysqladmin drop -f; mysqladmin create for reset), and using it by default will finally make people test their code on real rdbmses. -- С наилучшими пожеланиями, Boris __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
On 04/03/2015 08:55 PM, Morgan Fainberg 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. Killstabstabstabdiekillkill (yes please) __ 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
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
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
