)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"132277bcd13bf22d8cf9cefba91e7c6592fc0d51","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b71f7189_b21aef9f","updated":"2023-07-12 18:02:28.000000000","message":"WIP since the sqlalchemy 2.0 series isn\u0027t done yet","commit_id":"8c43d38ee4bc97e0fcda3e543702b96d507480af"},{"author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"change_message_id":"8fce405398193273be6faa375e8c910548795802","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"12c855fb_bc2accf8","updated":"2024-04-04 22:12:23.000000000","message":"this error is a little strange\n\n    AttributeError: \u0027BatchOperations\u0027 object has no attribute \u0027rename_table\u0027\n    \nI was already able to run the migrations tests fully with sqlalchemy 2.0.x","commit_id":"a5f644db128709897cd27a41ca27a60be63b6f4a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"28c78c9cd3ccf8603c4b7857add90683a178c016","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7a05ee75_6aa4878a","in_reply_to":"12c855fb_bc2accf8","updated":"2024-04-05 10:35:32.000000000","message":"The issue isn\u0027t SQLAlchemy: it\u0027s alembic. Something\u0027s changed in 1.11.0 since the tests pass just fine with 1.9.4 (current upper-constraint version) and 1.10.4 (last working version). Any ideas?","commit_id":"a5f644db128709897cd27a41ca27a60be63b6f4a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3ffb64c76867daedfe4ac4907f5f2d4cf28e895f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"800e04d7_55d84dec","in_reply_to":"2d80ba66_90d967b3","updated":"2024-04-05 13:33:30.000000000","message":"Gotcha https://review.opendev.org/c/openstack/manila/+/915131","commit_id":"a5f644db128709897cd27a41ca27a60be63b6f4a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"5ae5e605a2b274cfec79d371fd97695b7e8a12a7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2d80ba66_90d967b3","in_reply_to":"7a05ee75_6aa4878a","updated":"2024-04-05 13:02:07.000000000","message":"Addressed in https://review.opendev.org/c/openstack/manila/+/915127/. The other two outstanding issues are SQLAlchemy 2.0 things though. I\u0027ve spent the last hour looking into it and I have no idea what\u0027s going on 😕","commit_id":"a5f644db128709897cd27a41ca27a60be63b6f4a"},{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"9708bdc8f23992c534e03170909efdbd2ddebd91","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"4cb6395d_7d83eb7f","updated":"2024-04-09 17:36:20.000000000","message":"Great to see this coming together and this job passing, Stephen and Mike! Thank you very much for all your hard work","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"0dad5229dfa90d2a0f8b08db08cd67948b68eec8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"b736e647_d8462193","updated":"2024-04-08 22:36:46.000000000","message":"Looks good for a temporary job; great to see it pass after all your efforts here!","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"change_message_id":"c5de54a2554e59426abf3da8f94a81f2c0a6c60d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"1e2ab56c_8908f833","updated":"2024-04-10 20:50:38.000000000","message":"The issue is that the test in `def test_share_snapshot_instance_access_get_all()` assumes that the ordering of `ShareSnapshotInstance.id` in the `self.snapshot_instances` collection will match the ordering that comes from the `ShareSnapshot.instances` collection when it is loaded in `_share_snapshot_get()`.  There is no ORDER BY in the SQL query here so there is no such guarantee.  the SQL query in 1.4 and 2.0 have a slightly different column ordering but are semantically equivalent; the difference in row ordering is an artifact of the database.\n\nRunning the test on SQLAlchemy 1.4, the contents of `[s.id for s in self.snapshot_instances]` is:\n\n    IDS: [\u0027b8829c29-e8be-4c9e-a46e-17a267982ce4\u0027, \u00272d829d97-542c-46bd-bde3-3c71620b96ba\u0027, \u002743bccfb0-4063-478e-9093-faef7b5cb77d\u0027, \u0027fake_snapshot_instance_id\u0027]\n\nThe query is a large joined eager loading query and runs as follows:\n\n    SELECT \n        anon_1.share_snapshots_created_at AS anon_1_share_snapshots_created_at, anon_1.share_snapshots_updated_at AS anon_1_share_snapshots_updated_at, ...\n        ---  lots of columns here omitted ---\n    FROM (SELECT -- lots of columns omitted ---\n    FROM share_snapshots\n    WHERE share_snapshots.deleted \u003d ? AND share_snapshots.id \u003d ?\n    LIMIT ? OFFSET ?) AS anon_1 \n    LEFT OUTER JOIN shares AS shares_1 ON anon_1.share_snapshots_share_id \u003d shares_1.id AND anon_1.share_snapshots_deleted \u003d ? \n    LEFT OUTER JOIN share_snapshot_metadata AS share_snapshot_metadata_1 ON share_snapshot_metadata_1.share_snapshot_id \u003d anon_1.share_snapshots_id AND share_snapshot_metadata_1.deleted \u003d ?\n    LEFT OUTER JOIN share_snapshot_instances AS share_snapshot_instances_1 ON anon_1.share_snapshots_id \u003d share_snapshot_instances_1.snapshot_id AND share_snapshot_instances_1.deleted \u003d ?\n\n\nThe rows then contain the share_snapshot_instance_id in the **same** order as were inserted:  \n\n    \u0027b8829c29-e8be-4c9e-a46e-17a267982ce4\u0027, \u00272d829d97-542c-46bd-bde3-3c71620b96ba\u0027, \u002743bccfb0-4063-478e-9093-faef7b5cb77d\u0027\n\nRows logged as (note the created_at date is first):\n\n    Row (datetime.datetime(2024, 4, 10, 20, 14, 30, 4700), None, None, \u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 29, 968444), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, None, None, None, None, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 29, 983462), None, None, \u0027b8829c29-e8be-4c9e-a46e-17a267982ce4\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u00277826076b-454f-43f5-ae06-48de7c12d3ee\u0027, \u0027creating\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None)\n    Row (datetime.datetime(2024, 4, 10, 20, 14, 30, 4700), None, None, \u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 29, 968444), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, None, None, None, None, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 29, 992723), None, None, \u00272d829d97-542c-46bd-bde3-3c71620b96ba\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u002735a6b51b-5e27-4860-996d-f9ea3d7d8550\u0027, \u0027error\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None)\n    Row (datetime.datetime(2024, 4, 10, 20, 14, 30, 4700), None, None, \u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 29, 968444), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, None, None, None, None, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 29, 995768), None, None, \u002743bccfb0-4063-478e-9093-faef7b5cb77d\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u0027b5a52b42-ac71-420c-9bb6-a0c779b24edb\u0027, \u0027deleting\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None)\n\n\nRunning the test on SQLAlchemy 2.0, the contents of `[s.id for s in self.snapshot_instances]` is:\n\n    IDS: [\u00279687b493-9f91-43fa-aa21-59caab2754cf\u0027, \u0027ef7c981b-79ad-4274-86f3-0c26b6a14040\u0027, \u0027859c17cf-9614-45c0-9486-ef5f0178f39f\u0027, \u0027fake_snapshot_instance_id\u0027]\n\nThe query is a large joined eager loading query and runs as follows - not illustrated here is the specific ordering of columns in the SELECT is different in SQLAlchemy 2.0, even though the same data is being loaded:\n\n    SELECT \n        anon_1.share_snapshots_id AS anon_1_share_snapshots_id, anon_1.share_snapshots_deleted AS anon_1_share_snapshots_deleted, ...    \n        --- lots of columns omitted ---\n    FROM (SELECT --- lots of columns omitted ---\n    FROM share_snapshots\n    WHERE share_snapshots.deleted \u003d ? AND share_snapshots.id \u003d ?\n    LIMIT ? OFFSET ?) AS anon_1 \n    LEFT OUTER JOIN shares AS shares_1 ON anon_1.share_snapshots_share_id \u003d shares_1.id AND anon_1.share_snapshots_deleted \u003d ? \n    LEFT OUTER JOIN share_snapshot_metadata AS share_snapshot_metadata_1 ON share_snapshot_metadata_1.share_snapshot_id \u003d anon_1.share_snapshots_id AND share_snapshot_metadata_1.deleted \u003d ?\n    LEFT OUTER JOIN share_snapshot_instances AS share_snapshot_instances_1 ON anon_1.share_snapshots_id \u003d share_snapshot_instances_1.snapshot_id AND share_snapshot_instances_1.deleted \u003d ?\n\n\nThe rows then contain the share_snapshot_instance_id in a **different** order than were inserted:\n\n    \u0027859c17cf-9614-45c0-9486-ef5f0178f39f\u0027, \u00279687b493-9f91-43fa-aa21-59caab2754cf\u0027, \u0027ef7c981b-79ad-4274-86f3-0c26b6a14040\u0027\n\nRows logged as (note different column ordering):\n\n    Row (\u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 3, 699923), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 660522), None, None, None, None, None, None, None, None, None, None, \u0027859c17cf-9614-45c0-9486-ef5f0178f39f\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u00272cbe917e-5ed3-44c6-9ae2-8f08d0dd1980\u0027, \u0027deleting\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 690443), None, None)\n    Row (\u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 3, 699923), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 660522), None, None, None, None, None, None, None, None, None, None, \u00279687b493-9f91-43fa-aa21-59caab2754cf\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u00271429b14f-d4e7-4911-b6a2-201ef06507f6\u0027, \u0027creating\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 676849), None, None)\n    Row (\u0027fake_snapshot_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, \u0027fake_share_id_1\u0027, 0, None, None, None, \u0027NFS\u0027, datetime.datetime(2024, 4, 10, 20, 14, 3, 699923), None, None, \u0027fake_share_id_1\u0027, \u0027False\u0027, \u0027fake\u0027, \u0027fake\u0027, 0, None, None, None, None, True, True, False, None, False, \u0027NFS\u0027, False, None, None, None, False, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 660522), None, None, None, None, None, None, None, None, None, None, \u0027ef7c981b-79ad-4274-86f3-0c26b6a14040\u0027, \u0027False\u0027, \u0027fake_snapshot_id_1\u0027, \u002745e7a7ec-e031-4ba0-bbc6-28867bdf21cc\u0027, \u0027error\u0027, \u00270%\u0027, \u0027fake_provider_location\u0027, None, None, None, None, None, datetime.datetime(2024, 4, 10, 20, 14, 3, 686593), None, None)\n\nfrom there, the resulting list of `ShareSnapshotInstanceAccessMapping` are made in the order from the above result set, which does not match the ordering of the `self.snapshot_instances` list.\n\nThe test therefore is modified to compare **all** entries keyed off of each identifier in `self.snapshot_instances` - so the data is confirmed as correct, just not in the same order.\n\nThere are also ways to add ORDER BY to the relationship but there\u0027s no key here that would faithfully reproduce \"insert order\", so this seems semantically to an unordered collection and no assumptions about its ordering should be made.","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"e4ae0e22792096ecf99d4f416f81c2b5246f8047","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"d1254b06_28ae92f1","updated":"2024-04-10 04:36:59.000000000","message":"recheck failure in manila.tests.db.sqlalchemy.test_api.ShareSnapshotDatabaseAPITestCase.test_share_snapshot_instance_access_get_all in the new job, might be unstable/racy?","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"29d4f2d196e16cbe5edf5fc179895ba592140ac0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"914e825d_2dcc1d42","updated":"2024-04-10 14:45:58.000000000","message":"same failure again in test_share_snapshot_instance_access_get_all in sqla2 job. so somehow this test is getting unstable with the new library","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"12e991159a80bd9e604e0a329e3ec56918a449b2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"9d2ebe66_cc1dbc6e","in_reply_to":"1e2ab56c_8908f833","updated":"2024-04-10 23:19:50.000000000","message":"\u003e The test therefore is modified to compare all entries keyed off of each identifier in self.snapshot_instances - so the data is confirmed as correct, just not in the same order.\n\nThat\u0027s certainly a great improvement to the test logic\n\n\u003e There are also ways to add ORDER BY to the relationship but there\u0027s no key here that would faithfully reproduce \"insert order\", so this seems semantically to an unordered collection and no assumptions about its ordering should be made.\n\nI agree; it seems like a misconception due to things working implicitly prior. The ordering doesn\u0027t matter to the core logic here; just this test; so fixing it was the right call.","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":11816,"name":"mike_mp@zzzcomputing.com","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"change_message_id":"1e4537e0930aec565e528bd5b8fd1218d3e654a2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"8eac80bb_8db1440b","in_reply_to":"914e825d_2dcc1d42","updated":"2024-04-10 20:51:14.000000000","message":"see my top level comment which fixes the test to not rely upon random ordering of rows.","commit_id":"18119181e030eb01b48011c84516c31bc7c08fda"},{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"c9bbd37692c73048de2e95d8c1d1201b50f78a8b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"619602b6_57230236","updated":"2024-04-11 17:36:55.000000000","message":"LGTM, thank you!","commit_id":"2a9ac87cc412431b268aba40729e144bd34bdf32"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"12e991159a80bd9e604e0a329e3ec56918a449b2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"089ff6e9_9aacf861","updated":"2024-04-10 23:19:50.000000000","message":"Thanks Mike; the job\u0027s passing now","commit_id":"2a9ac87cc412431b268aba40729e144bd34bdf32"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"7beea4e42e96de39c738b08d0015ee2dc47e9b2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"392657fd_0178c91d","updated":"2024-04-11 14:17:34.000000000","message":"cool, thx","commit_id":"2a9ac87cc412431b268aba40729e144bd34bdf32"}]}