Re: [OpenStack-Infra] Radware's service account request for third party testing
Hi Jeremy, I'm having trouble even commenting, could you verify that the public key is correct. ssh -p 29418 radware3rdpartytest...@review.openstack.org gerrit review -m 'Testing radware 3rd party testing account' 5f4224c41e2fb4e178572185e112c346ce1b362d Permission denied (publickey). ssh-rsa B3NzaC1yc2EDAQABAAABAQC8M8Y+d0xrwtuwgwanCbab9cNrh5tUGR7Yo2jPinbnWkTQNrrOJQ352Z3NOpJ98D3a985pUebbuh4vXBPyXD481sKGy+6BLsid9g6vVFhSuovDTSIaLoG8EbDi8Uv6r84DLf0x1cFFSsqA/si7YvA1BQsQ4dMIA3DyUJjsgvaaVlyT0W/x9noOgtfEkMGznjrfGp5Rn2KiFlpPbD2xq66q4EJ7Eazn+gqv3qXIbib91Ms1xwz38kH6DJlWJHtMVvZ/3wnIl8ivJpqFX0sHo2G5JLBQkY9eVrwWSCHdtsi+aMHuI3L+A3C7n3gB1GjfEW+qIJ9AeH+YSYb6gCap+aQJ openstack3rdpartytest...@radware.com Thanks, Izik P. -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Wednesday, March 26, 2014 3:53 PM To: Evgeny Fedoruk; OpenStack3RDPartyTesting; Samuel Bercovici; Avishay Balderman Cc: openstack-infra@lists.openstack.org Subject: Re: [OpenStack-Infra] Radware's service account request for third party testing On 2014-03-25 12:52:06 + (+), Mark McClain wrote: I haven’t seen any recent comments from the Radware test system. If we’re blocking commenting, might make sense to reenable commenting to see if they’re compliant but not allow voting. When I was originally asked to disallow that account from leaving extra comments on reviews[1] I did so by removing its SSH key. I have since re-added it, so please re-test and let me know whether it's working again. Thanks! [1] URL: http://lists.openstack.org/pipermail/openstack-infra/2014-January/000654.html -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Radware's service account request for third party testing
On 2014-03-26 14:55:16 + (+), Izik Penso wrote: I'm having trouble even commenting, could you verify that the public key is correct. The authentication credentials for that account may have been cached. I've just now flushed the cache in Gerrit, so see if that helped at all. If not, I'll go diving in its SSH log for a better answer. -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Radware's service account request for third party testing
It's working. Thanks. Izik Penso. -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Wednesday, March 26, 2014 5:16 PM To: Izik Penso Cc: Evgeny Fedoruk; OpenStack3RDPartyTesting; Samuel Bercovici; Avishay Balderman; openstack-infra@lists.openstack.org Subject: Re: [OpenStack-Infra] Radware's service account request for third party testing On 2014-03-26 14:55:16 + (+), Izik Penso wrote: I'm having trouble even commenting, could you verify that the public key is correct. The authentication credentials for that account may have been cached. I've just now flushed the cache in Gerrit, so see if that helped at all. If not, I'll go diving in its SSH log for a better answer. -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Moving some projects around
We've been discussing the thoroughly interesting problem of project taxonomy recently, and I'd like to describe what I think we've mostly decided we should do and make sure we're on the same page. If we are, I'll invite the TC to weigh in and if they think we're completely wrong, we can work on some policy. Move the following projects to the openstack-attic/ org (because they are no longer active projects though they had some degree of officialness about them at the time they were active): * openstack-dev/openstack-qa * openstack/melange * openstack/python-melangeclient * openstack/openstack-chef We should make these read-only as well. Leave openstack-dev/sandbox where it is. It's a useful tool for new openstack developers and third party CI systems -- it should be considered part of the openstack development process. Move openstack/python-openstackclient to stackforge. It's apparently a project without an official program. (Incidentally, this makes me sad.) Leave openstack/gantt where it is, but make it read-only. The current state of development is considered a dead end, but there is likely to be a future attempt (and therefore future openstack/gantt repository). Rather than rename it and rename it back, or rename it to something like openstack-attic/gant-mark-one, we think mothballing it and then replacing the entire branch with a merge commit for the second forklift attempt (like we did with keystone-lite) is the least silly option and actually faithfully represents development history. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [infra] Meeting Tuesday March 25th at 19:00 UTC
On Mon, Mar 24, 2014 at 10:35 AM, Elizabeth Krumbach Joseph l...@princessleia.com wrote: Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday March 25th, at 19:00 UTC in #openstack-meeting Meeting minutes and logs from yesterday here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-25-19.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-25-19.01.txt Log: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-25-19.01.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Moving some projects around
On Wed, Mar 26, 2014 at 1:50 PM, James E. Blair jebl...@openstack.orgwrote: We've been discussing the thoroughly interesting problem of project taxonomy recently, and I'd like to describe what I think we've mostly decided we should do and make sure we're on the same page. If we are, I'll invite the TC to weigh in and if they think we're completely wrong, we can work on some policy. Move the following projects to the openstack-attic/ org (because they are no longer active projects though they had some degree of officialness about them at the time they were active): * openstack-dev/openstack-qa * openstack/melange * openstack/python-melangeclient * openstack/openstack-chef We should make these read-only as well. Leave openstack-dev/sandbox where it is. It's a useful tool for new openstack developers and third party CI systems -- it should be considered part of the openstack development process. Move openstack/python-openstackclient to stackforge. It's apparently a project without an official program. (Incidentally, this makes me sad.) Dean may be ready to propose that as a program. Have you asked? It might save moving it twice. Doug Leave openstack/gantt where it is, but make it read-only. The current state of development is considered a dead end, but there is likely to be a future attempt (and therefore future openstack/gantt repository). Rather than rename it and rename it back, or rename it to something like openstack-attic/gant-mark-one, we think mothballing it and then replacing the entire branch with a merge commit for the second forklift attempt (like we did with keystone-lite) is the least silly option and actually faithfully represents development history. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Using MySQL for unit tests in storyboard
Hi, I recently started looking into running the unit tests with MySQL. I pushed the start of a change here to do that: https://review.openstack.org/#/c/82872/ In particular, that change implements something we've wanted to do for a long time elsewhere in OpenStack -- create a dedicated MySQL database for each test so that tests can safely run in parallel. However, that has uncovered the following issues: * The tests do not use alembic, except for the migration test. This could lead to variations in what the unit tests are testing against as compared to production. * The model does not specify an engine for MySQL (this is a difference between the model and the alembic migrations). So when the unit tests are run on MySQL, they may end up on MyISAM (they do in the gate). * The two errors that show up in the test results for my patch relate to how timestamps are stored differently between MySQL and SQLite. * The errors that you can not see in the test report from Jenkins but would if you ran in an environment with InnoDB as the default engine for MySQL are several instances of foreign key constraint errors. I think it is desirable to run the unit tests with MySQL largely because I think we should be testing it in the way we intend to use it in production. Note especially the last point above -- our unit tests have significant problems with MySQL. That suggests one of two things to me: either the tests aren't testing real behavior, or our system is actually broken in production. Neither one seems like a good situation. My inclination would be to use MySQL for unit tests, use alembic to create the schema, and fix the errors currently uncovered by this. It's not going to be a trivial change, but I think it's worth doing. Before embarking on it, I'd like to see if we can get consensus. We can talk about it here or possibly at the meeting tomorrow. Ruslan has commented in that review with the following: But, I think that we should consider work done in major OpenStack projects. They don't use real MySQL to run unit-tests. Here is what the do (or plan to do): * Run unit-tests on SQLite. DB schema is created from SQLA metadata * Run DB migration tests on MySQL and Postgres * Run tests to compare SQLA metadata and DB migrations to make sure that they're in sync. Here is WIP patch https://review.openstack.org/#/c/ I'm not opposed to this direction, I just want to make sure we're aligned with the common practices in OpenStack (That last link doesn't seem to be correct.) That's a good point, but I personally find testing as close to production as possible desirable -- MySQL and SQLite are not compatible so we shouldn't pretend that they are. If we prove this is a viable strategy, then I think we should recommend OpenStack projects adopt it as well. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard
Clint Byrum cl...@fewbar.com writes: * The model does not specify an engine for MySQL (this is a difference between the model and the alembic migrations). So when the unit tests are run on MySQL, they may end up on MyISAM (they do in the gate). Why MyISAM? The default has been InnoDB since MySQL 5.5. We override the default storage engine on our test nodes to be MyISAM specifically so that we catch errors like this. It used to be a big problem with Nova. Perhaps enough time has passed that we can say that it is inconceivable that anyone anywhere would be running on a system where myisam is the default. I'm not prepared to vouch for that. :) * The two errors that show up in the test results for my patch relate to how timestamps are stored differently between MySQL and SQLite. Isn't this a bug in sqlalchemy? I'd expect any data type that is a common name in the two databases (and thus the same in the model definition) to produce the same data in the python representation. After reading the SQLite docs, I know less than I did before. Apparently DATETIME might be stored as TEXT, REAL, or INTEGER values. In practice, the sqlite databases created by the current unit tests seem to end up with TEXT values, because they store values like 2014-03-26 21:11:13.304460. According to the docs, MySQL accepts but discards sub-second values. The error is that the value it gets back from MySQL lacks the part after the decimal point; when the test is run with SQLite, it is retained. * The errors that you can not see in the test report from Jenkins but would if you ran in an environment with InnoDB as the default engine for MySQL are several instances of foreign key constraint errors. Side note: IMHO: Just drop the FK constraints if you want the app to be scalable. FK's just add extra reads for every write, when you could be doing that verification / orphan clean up offline later on. I would like to do that. That might even be my preferred way of addressing this problem. I just haven't dug into it yet figuring we could probably answer the present question should we require mysql for tests independently; perhaps they will end up being more related than I thought. I think it is desirable to run the unit tests with MySQL largely because I think we should be testing it in the way we intend to use it in production. Note especially the last point above -- our unit tests have significant problems with MySQL. That suggests one of two things to me: either the tests aren't testing real behavior, or our system is actually broken in production. Neither one seems like a good situation. Wouldn't integration tests be the place to find production vs. code path issues? Tying unit tests to the creation of mysql databases introduces a really big piece of machinery into the test fixture setup, which you want to be fast and lean so developers can iterate on it while working. Then I'm not sure what the database unit tests are testing. Basically, Storyboard's short history of CD is that it frequently gets wedged because it's never tested under a production configuration. If you are arguing that an integration test in this context is integrate storyboard and mysql and see if they work together, that does make sense. However, I would argue that storyboard itself doesn't (and shouldn't) work _without_ mysql It certainly requires a database. Instead our unit tests are currently integration tests where we integrate storyboard with a component (sqlite) that is never used when running it. Regardless of semantics, I see it as a fairly clear dichotomy: we either test with a component we don't use, or we test with the one we do use. I would prefer the latter. That's a good point, but I personally find testing as close to production as possible desirable -- MySQL and SQLite are not compatible so we shouldn't pretend that they are. If we prove this is a viable strategy, then I think we should recommend OpenStack projects adopt it as well. I just wonder if SQLAlchemy is intended to smooth out the differences between the two in such a way where you can at least be confident that your code is doing what you think it is. I'm not sure whether it's intended to do that, but I don't believe it does that very well. In practice, to write a good application you have to know a lot about exactly what your database is doing. If you write against two databases, then you still need to know twice as much. For a while now, I have considered SQLAlchemy (and ORMs in general) as very useful tools to map between an application model and databases, but I've ceased considering them to be an abstraction layer. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard
On Thu, Mar 27, 2014 at 12:30 AM, James E. Blair jebl...@openstack.org wrote: Ruslan has commented in that review with the following: But, I think that we should consider work done in major OpenStack projects. They don't use real MySQL to run unit-tests. Here is what the do (or plan to do): * Run unit-tests on SQLite. DB schema is created from SQLA metadata * Run DB migration tests on MySQL and Postgres * Run tests to compare SQLA metadata and DB migrations to make sure that they're in sync. Here is WIP patch https://review.openstack.org/#/c/ I'm not opposed to this direction, I just want to make sure we're aligned with the common practices in OpenStack (That last link doesn't seem to be correct.) Here is the link: https://review.openstack.org/#/c/74081/ ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard
On Wed, Mar 26, 2014 at 4:30 PM, James E. Blair jebl...@openstack.orgwrote: Hi, I recently started looking into running the unit tests with MySQL. I pushed the start of a change here to do that: https://review.openstack.org/#/c/82872/ In particular, that change implements something we've wanted to do for a long time elsewhere in OpenStack -- create a dedicated MySQL database for each test so that tests can safely run in parallel. However, that has uncovered the following issues: * The tests do not use alembic, except for the migration test. This could lead to variations in what the unit tests are testing against as compared to production. * The model does not specify an engine for MySQL (this is a difference between the model and the alembic migrations). So when the unit tests are run on MySQL, they may end up on MyISAM (they do in the gate). * The two errors that show up in the test results for my patch relate to how timestamps are stored differently between MySQL and SQLite. * The errors that you can not see in the test report from Jenkins but would if you ran in an environment with InnoDB as the default engine for MySQL are several instances of foreign key constraint errors. I think it is desirable to run the unit tests with MySQL largely because I think we should be testing it in the way we intend to use it in production. Note especially the last point above -- our unit tests have significant problems with MySQL. That suggests one of two things to me: either the tests aren't testing real behavior, or our system is actually broken in production. Neither one seems like a good situation. My inclination would be to use MySQL for unit tests, use alembic to create the schema, and fix the errors currently uncovered by this. It's not going to be a trivial change, but I think it's worth doing. Before embarking on it, I'd like to see if we can get consensus. We can talk about it here or possibly at the meeting tomorrow. Ruslan has commented in that review with the following: But, I think that we should consider work done in major OpenStack projects. They don't use real MySQL to run unit-tests. Here is what the do (or plan to do): * Run unit-tests on SQLite. DB schema is created from SQLA metadata * Run DB migration tests on MySQL and Postgres * Run tests to compare SQLA metadata and DB migrations to make sure that they're in sync. Here is WIP patch https://review.openstack.org/#/c/ I'm not opposed to this direction, I just want to make sure we're aligned with the common practices in OpenStack (That last link doesn't seem to be correct.) That's a good point, but I personally find testing as close to production as possible desirable -- MySQL and SQLite are not compatible so we shouldn't pretend that they are. If we prove this is a viable strategy, then I think we should recommend OpenStack projects adopt it as well. Some of the folks from Mirantis who are working on oslo.db are working on making it so we can use the models to create a database in our unit tests, and then compare the resulting database with what the migrations do. That *should* speed up tests, since we don't have to apply a set of migrations, while still ensuring that we are testing using the same schema. It also has the benefit of ensuring that our models represent what the migrations create. I've copied Victor and Roman on this so they can add more detail. Doug -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard
On Wed, Mar 26, 2014 at 6:24 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Wed, Mar 26, 2014 at 4:30 PM, James E. Blair jebl...@openstack.orgwrote: Hi, I recently started looking into running the unit tests with MySQL. I pushed the start of a change here to do that: https://review.openstack.org/#/c/82872/ In particular, that change implements something we've wanted to do for a long time elsewhere in OpenStack -- create a dedicated MySQL database for each test so that tests can safely run in parallel. However, that has uncovered the following issues: * The tests do not use alembic, except for the migration test. This could lead to variations in what the unit tests are testing against as compared to production. * The model does not specify an engine for MySQL (this is a difference between the model and the alembic migrations). So when the unit tests are run on MySQL, they may end up on MyISAM (they do in the gate). * The two errors that show up in the test results for my patch relate to how timestamps are stored differently between MySQL and SQLite. * The errors that you can not see in the test report from Jenkins but would if you ran in an environment with InnoDB as the default engine for MySQL are several instances of foreign key constraint errors. I think it is desirable to run the unit tests with MySQL largely because I think we should be testing it in the way we intend to use it in production. Note especially the last point above -- our unit tests have significant problems with MySQL. That suggests one of two things to me: either the tests aren't testing real behavior, or our system is actually broken in production. Neither one seems like a good situation. My inclination would be to use MySQL for unit tests, use alembic to create the schema, and fix the errors currently uncovered by this. It's not going to be a trivial change, but I think it's worth doing. Before embarking on it, I'd like to see if we can get consensus. We can talk about it here or possibly at the meeting tomorrow. Ruslan has commented in that review with the following: But, I think that we should consider work done in major OpenStack projects. They don't use real MySQL to run unit-tests. Here is what the do (or plan to do): * Run unit-tests on SQLite. DB schema is created from SQLA metadata * Run DB migration tests on MySQL and Postgres * Run tests to compare SQLA metadata and DB migrations to make sure that they're in sync. Here is WIP patch https://review.openstack.org/#/c/ I'm not opposed to this direction, I just want to make sure we're aligned with the common practices in OpenStack (That last link doesn't seem to be correct.) That's a good point, but I personally find testing as close to production as possible desirable -- MySQL and SQLite are not compatible so we shouldn't pretend that they are. If we prove this is a viable strategy, then I think we should recommend OpenStack projects adopt it as well. Some of the folks from Mirantis who are working on oslo.db are working on making it so we can use the models to create a database in our unit tests, and then compare the resulting database with what the migrations do. That *should* speed up tests, since we don't have to apply a set of migrations, while still ensuring that we are testing using the same schema. It also has the benefit of ensuring that our models represent what the migrations create. I've copied Victor and Roman on this so they can add more detail. And, that's the same work Ruslan was linking to based on his follow-up message. Doug Doug -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
