)]}'
{"id":"openstack%2Foctavia~720244","triplet_id":"openstack%2Foctavia~master~I7910ebe4cff692bab67349bbf3e4ee4e24b5fa7a","project":"openstack/octavia","branch":"master","hashtags":[],"change_id":"I7910ebe4cff692bab67349bbf3e4ee4e24b5fa7a","subject":"Disable two tests due to sqlalchemy/sqlite bug","status":"MERGED","created":"2020-04-15 17:08:02.000000000","updated":"2020-04-16 04:10:43.000000000","submitted":"2020-04-15 20:04:25.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":0,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"720244-1586981065719-0447f3fa","meta_rev_id":"74806cc33fdb3781655d93d775c91b1e50424e35","_number":720244,"virtual_id_number":720244,"owner":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"tag":"autogenerated:zuul:gate","value":2,"date":"2020-04-15 20:04:25.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},{"value":0,"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","default_value":0,"optional":true},"Code-Review":{"approved":{"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":2,"date":"2020-04-15 17:33:15.000000000","_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},{"value":2,"date":"2020-04-15 17:50:32.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"approved":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},{"value":1,"date":"2020-04-15 17:50:32.000000000","permitted_voting_range":{"min":1,"max":1},"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Backport-Candidate":{"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},{"value":0,"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"}],"values":{"-2":"Do Not Backport","-1":"Not A Backport Candidate"," 0":"Backport Review Needed","+1":"Proposed Backport","+2":"Should Backport"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2020-04-15 17:33:15.000000000","updated_by":{"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},"reviewer":{"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},"state":"REVIEWER"},{"updated":"2020-04-15 17:50:32.000000000","updated_by":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"reviewer":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"state":"REVIEWER"},{"updated":"2020-04-15 20:04:25.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"}],"messages":[{"id":"832f29c9933977be63125e98214176be66255e03","author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"date":"2020-04-15 17:08:02.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"8a4ae0f6f8cf7470d40f733f7bc5c1179bbb1203","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-15 17:30:38.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/3c53d50fd5534853962d82f64c5970cb : SUCCESS in 11m 47s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/ef12ee9a4eed441192f997cebe28628e : SUCCESS in 10m 31s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/82961a36db7e409b8fe7b5d24b4fca8c : SUCCESS in 7m 17s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/b051d684faab4edfab6a4b78b282cc23 : SUCCESS in 7m 48s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/764facd9997b4e6faa635d078a2cd176 : SUCCESS in 6m 47s\n- openstack-tox-py38 https://zuul.opendev.org/t/openstack/build/fb1da3b823ad4c30945f62ae42f4925a : SUCCESS in 7m 46s (non-voting)\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/1f78c7082387465ebd82263d3e32c974 : SUCCESS in 15m 25s\n- octavia-tox-py37-tips https://zuul.opendev.org/t/openstack/build/5f9476a47d924ffc8f1bdc9982288e4d : SUCCESS in 7m 27s\n- octavia-tox-functional-py37-tips https://zuul.opendev.org/t/openstack/build/b4d88458f7934b339707b5233821bc27 : SUCCESS in 9m 11s\n- openstack-tox-functional-py36 https://zuul.opendev.org/t/openstack/build/83e38c67e2a54c95806c67acf5c9521c : SUCCESS in 8m 49s","accounts_in_message":[],"_revision_number":1},{"id":"4818bf6cf643d02011920359e6e327f8bb0e2141","author":{"_account_id":6469,"name":"Carlos Gonçalves","display_name":"Carlos Goncalves","email":"cgoncalves@redhat.com","username":"cgoncalves"},"date":"2020-04-15 17:33:15.000000000","message":"Patch Set 1: Code-Review+2","accounts_in_message":[],"_revision_number":1},{"id":"10c3190e0059833041291521cb4064f77fbfa5fe","author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"date":"2020-04-15 17:50:32.000000000","message":"Patch Set 1: Code-Review+2 Workflow+1","accounts_in_message":[],"_revision_number":1},{"id":"b22becd99224223360e9c26f33197907cf3ee9c5","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-15 17:50:43.000000000","message":"Patch Set 1: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":1},{"id":"b99e7b862727b6458e1ed8a498f5937c655b5103","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-15 20:04:25.000000000","message":"Patch Set 1: Verified+2\n\nBuild succeeded (gate pipeline).\n\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/de48cec8c14942279cbb95bf74d44624 : SUCCESS in 13m 00s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/eb3ac552d6a24b32b6575ffee3eead45 : SUCCESS in 7m 06s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/6a1695671ee142ac936540934ceee3ad : SUCCESS in 5m 35s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/b3c9286214684c68b1a794e0cabbef70 : SUCCESS in 7m 39s\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/4b735d2063f34946963914ce63ab1d6f : SUCCESS in 16m 35s\n- openstack-tox-functional-py36 https://zuul.opendev.org/t/openstack/build/27326dde26d54fee9c95cccc513cc41a : SUCCESS in 9m 00s\n- octavia-v2-dsvm-noop-api https://zuul.opendev.org/t/openstack/build/0f81615d88784df5964a2db7bb6ad1e0 : SUCCESS in 45m 31s\n- octavia-v2-dsvm-scenario https://zuul.opendev.org/t/openstack/build/35448e615d904d1285ff9dafa0e81dc1 : SUCCESS in 2h 11m 49s\n- octavia-v2-dsvm-tls-barbican https://zuul.opendev.org/t/openstack/build/13459c8aeda042c19800ab3eb9304941 : SUCCESS in 1h 10m 58s\n- octavia-v2-dsvm-spare-pool https://zuul.opendev.org/t/openstack/build/620139ede34543be899c80d50aafb4f7 : SUCCESS in 1h 07m 28s\n- octavia-v2-act-stdby-dsvm-scenario https://zuul.opendev.org/t/openstack/build/d9013270db934aed9727a809a9407300 : SUCCESS in 1h 16m 25s","accounts_in_message":[],"_revision_number":1},{"id":"51042228c3a439eca32dbe258ce41927eadc89ed","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-15 20:04:25.000000000","message":"Change has been successfully merged by Zuul","accounts_in_message":[],"_revision_number":1},{"id":"e34d9f491cf2972fa4e812acb44aabd5f8e3578a","tag":"autogenerated:zuul:promote","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-15 20:06:29.000000000","message":"Patch Set 1:\n\nBuild succeeded (promote pipeline).\n\n- promote-openstack-tox-docs https://zuul.opendev.org/t/openstack/build/0e2c95ef608b4050b1752c309795b90d : SUCCESS in 1m 35s","accounts_in_message":[],"_revision_number":1},{"id":"e843fa6226a9f88b2ff99c81fa24d1c8520d0b29","author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"date":"2020-04-16 02:32:40.000000000","message":"Patch Set 1:\n\nhi there -\n\nIn discussions w/ Adam, I was under the impression we had determined that something was different about SQLite in some particular CI environment.   SQLAlchemy 1.3.16 does not change anything about how it handles SQLite tranasctions, and if it does, that needs to be reported as a bug.  The commit noted changes nothing at all about the behavior of the SQLite dialect other than that a new isolation level \"AUTOCOMMIT\" is now supported; if this isolation mode is not explicitly selected, then nothing changes at all.  There is zero chance that this isolation level is being used because prior to 1.3.16 attempting to use \"AUTOCOMMIT\" with SQLite would raise an error.   The set_isolation_level() method is also not called unless the calling application invokes it directly.   oslo.db itself actually disables SQLite\u0027s isolation handling in any case, and it does this by manipulating the SQlite connection itself, not by calling this method.\n\nBasically the method shown should not be getting called at all, and in order to identify if some change in SQLAlchemy is affecting this, git bisect should be used.","accounts_in_message":[],"_revision_number":1},{"id":"b865ecb2a5114e45ba2054493e86722aa2af434d","author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"date":"2020-04-16 02:51:18.000000000","message":"Patch Set 1:\n\nI can confirm SQLAlchemy\u0027s set_isolation_level method is not called within the scope of running test_repostitories.  I can\u0027t reproduce any failure in these tests however I changed every set_isolation_level() method to raise NotImplementedError() and the tests complete successfully without the method ever being invoked.    There are no other changes that involve transaction handling between 1.3.15 and 1.3.16 so it\u0027s critical that the reproduction case be identified here.","accounts_in_message":[],"_revision_number":1},{"id":"74806cc33fdb3781655d93d775c91b1e50424e35","author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"date":"2020-04-16 04:10:43.000000000","message":"Patch Set 1:\n\nOK also I have identified why the test_sqlite_transactions_broken has the behavior that it does and it is not really any kind of \"bug\" in SQLite, it is somewhat related to a pysqlite behavior that oslo.db tries to work around which makes the behavior more confusing here.  I haven\u0027t looked at the other tests yet to see what they are trying to do, but the basic idea is pretty much what it sounded like when Adam first contacted me on IRC, where I mentioned that if SQLite is being used with a \"memory\" database, it is not possible to do any kind of tests where you are simulating multiple transactions or anything else like that going on.\n\nThe simple issue in this test is that it uses two ORM sessions but these two sessions use the exact same SQLite :memory: connection, and when the \"session\" is used to emit any kind of SQL, a new  SQLAlchemy \"Connection\" object is fired up which assumes this SQLite connection is unique to it, and when it is done, which in this case is the moment that \"count()\" query is over, it \"returns\" the SQLite connection to the connection pool which then calls an implicit rollback on the connection.   Then the method proceeds to INSERT a row which in fact is occurring in autocommit mode because there is no transaction.\n\nSo the first thing to note is, when you use a SQLite :memory: connection, that\u0027s not a file handle or a socket, that\u0027s a single SQLite connection with the database state inside of it as an in-memory structure, and it is not accessible from any other \"connection\".   It is not possible to perform any kind of action or test that is in any way pretending there is more than one transaction going on at a time on that same \"database\".   So the first fact that this test is trying to use \"session\" and \"lock_session\" separately would appear to misunderstand this; it will never do anything useful, and with the particular changes that oslo.db makes to the state of the SQLite connection, you will get behavior that appears broken as it does here.\n\nSQLAlchemy allows the SQLite \"memory\" database connection to be useful by maintaining just that single connection in memory and each time you \"connect\" via the engine, you get that same connection back.   You can of course modify this behavior but as sqlite memory is usually used for test suites, it ends up being fairly convenient and people like that when they disconnect and reconnect again to their \"database\", the data is still there.\n\noslo.db makes a small adjustment to SQLAlchemy\u0027s behavior here by plugging in a connection pool called the SingletonPool, which explicitly holds onto just that one connection, but this is only adjusting that SQLAlchemy normally uses a similar pool that does the same thing on a thread-local-only basis, nobody is using threads or greenlets here, it is the same either way within these tests.\n\nbut then oslo.db is making another change that is where the behavior here starts to get more confusing, which is that it is disabling pysqlite\u0027s handling of transaction boundaries on the SQLite connection in order to try to work around a known pysqlite issue that is not really an issue for anyone, but someone in openstack apparently had an issue with it thus leading to oslo.db to gain this behavior at some point.  So what happens is instead of pysqlite emitting BEGIN for a transaction when some important SQL is detected, it is instead not doing it at all, and oslo.db is instead emitting the BEGIN whenever SQLAlchemy is told to officially BEGIN a transaction, which when using oslo.db enginefacade or any other usual openstack service method is always, however as openstack is not standardized on non-\"autocommit\" sessions (which have long been advised against and are going away fully in an upcoming major release), we often see these sessions sneaking in without calling these events as is the case in this test.\n\noslo.db is using this workaround: https://docs.sqlalchemy.org/en/13/dialects/sqlite.html#pysqlite-serializable  which basically says, pysqlite will not emit BEGIN at all, oslo.db will.    So what that means is that we are now relying heavily upon SQLAlchemy\u0027s connection-level transaction events in order to ensure that the start of the transaction is demarcated correctly.  However, test_sqlite_transactions_\"broken\" is going in there and using two Sessions at the same time, which are both on the same Engine, same connection pool, same SQLite :memory: connection, and the session which does the count is in autocommit mode and does not call begin(), so it\u0027s doing a connection checkout, not doing any kind of transactional anything and neither is pysqlite because oslo.db told it not to, then it cleans up after itself, returns the connection to the pool which does a rollback() on it (the connection pool does this because usually all Python DBAPIs are starting transactions implicitly, except not in this case due to the oslo.db change).   The lock_session, which interestingly is using autocommit\u003dFalse,  is still sitting there with that same connection still checked out (because it\u0027s autocommit\u003dFalse) which has now had \"ROLLBACK\" called on it, and it\u0027s in autocommit mode.\n\nthe same test can be illustrated more succinctly like this:\n\n        lock_session \u003d db_api.get_session(autocommit\u003dFalse)\n\n        # lock_session checks out a connection, begins a transaction.\n        # oslo.db emits \"BEGIN\" on the connection.\n        lbs \u003d lock_session.query(db_models.LoadBalancer).filter_by(\n            project_id\u003dproject_id).all()\n        self.assertEqual(0, len(lbs))  # After rollback: 0\n\n        # send an unexpected \"rollback\" on the SQLite connection,\n        # now we\u0027re in autocommit.  this is basically what using another\n        # session in autocommit mode is doing.\n        conn \u003d lock_session.bind.connect()\n        conn.execute(\"rollback\")\n\n        # insert some data, it\u0027s all committed\n        self.repos.create_load_balancer_and_vip(lock_session, lb, vip)\n\n        # sure\n        lbs \u003d lock_session.query(db_models.LoadBalancer).filter_by(\n            project_id\u003dproject_id).all()\n        self.assertEqual(1, len(lbs))  # After create: 1\n\n        # does nothing\n        lock_session.rollback()\n\n        lbs \u003d lock_session.query(db_models.LoadBalancer).filter_by(\n            project_id\u003dproject_id).all()\n        self.assertEqual(1, len(lbs))  # data was autocommited - not broken!\n\n\nBasically, this test and others that are depending on similar concepts can\u0027t do anything that attempts to work with multiple sessions simultaneously on a SQLite memory database.  if you have tests that are exercising assumptions related to transaction isolation you should use a MySQL fixture against InnoDB tables.\n\nIt\u0027s late here so this came out a little rambly but I hope it can be helpful in any case.","accounts_in_message":[],"_revision_number":1}],"current_revision_number":1,"current_revision":"ccd6c3875eaec3978fbe970e11d04db8a3c29b0c","revisions":{"ccd6c3875eaec3978fbe970e11d04db8a3c29b0c":{"kind":"REWORK","_number":1,"created":"2020-04-15 17:08:02.000000000","uploader":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"ref":"refs/changes/44/720244/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/octavia","ref":"refs/changes/44/720244/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/octavia refs/changes/44/720244/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/octavia refs/changes/44/720244/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/octavia refs/changes/44/720244/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/octavia refs/changes/44/720244/1"}}},"commit":{"parents":[{"commit":"c9e155155087931381d740e2ae6eef8dd7b7fafd","subject":"Imported Translations from Zanata","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/octavia/commit/c9e155155087931381d740e2ae6eef8dd7b7fafd"}]}],"author":{"name":"Michael Johnson","email":"johnsomor@gmail.com","date":"2020-04-15 17:01:03.000000000","tz":-420},"committer":{"name":"Michael Johnson","email":"johnsomor@gmail.com","date":"2020-04-15 17:08:00.000000000","tz":-420},"subject":"Disable two tests due to sqlalchemy/sqlite bug","message":"Disable two tests due to sqlalchemy/sqlite bug\n\nThis patch adds a test skip for two tests that are impacted by the\nrecent sqlalchemy 1.3.16 release.\nWith this release, a patch[1], changes the default commit behavior\nof a transaction. With this change we are seeing that the load\nbalancer created in the tree-create test disappears from the\ntransaction context during the test and the pool create call will\nthrow a foreign key error as the load balancer is not in the database.\n\nIt\u0027s not clear if this is purely a sqlalchemy, pysqlite, or sqlite3\nbug at this time.\nGiven the requirements are already in freeze for the Ussuri release,\nwe are opting to disable the tests (we know only sqlite is impacted),\ninstead of attempt to blacklist 1.3.16 in requirements.\n\n[1] https://github.com/sqlalchemy/sqlalchemy/commit/9ebbf8614a24fbc430365f6e76c9fd04616992fa#diff-e9762e21a27d8e6c44db6f9dd4edc694R455\n\nChange-Id: I7910ebe4cff692bab67349bbf3e4ee4e24b5fa7a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/octavia/commit/ccd6c3875eaec3978fbe970e11d04db8a3c29b0c"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/octavia/commit/ccd6c3875eaec3978fbe970e11d04db8a3c29b0c"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}