)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"4a91200cb0c8eb83c7155778d52c3f79ff31fa67","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"a03a969d_c4d2651b","updated":"2025-03-25 14:56:02.000000000","message":"This change could be made into oslo.db to expose it (even though it\u0027s a bad idea for operations to change it unless they know the codebase itself), but changing this by default means that all codebases that use this context manager would need an audit for race conditions and we would indeed need to add CI testing with a slave_connection to test for races.","commit_id":"5990d2f1ec4e9af315dcd93dc925e6af71eeb8ce"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"9fe10a168d0b68f7da270be18928325537488a46","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5f9efc0a_423e3ff9","updated":"2025-03-24 12:55:04.000000000","message":"if I understand well we will not see the effect of this setting in upstream CI, am I right?","commit_id":"5990d2f1ec4e9af315dcd93dc925e6af71eeb8ce"},{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"2c2e58251d426c7390372476c9df849e09d6661a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"06459779_4f9fe393","in_reply_to":"5f9efc0a_423e3ff9","updated":"2025-03-24 21:10:52.000000000","message":"I havn´t check yet how CI is configured, but I believe there is only one user?\nIs the slave_connection set in ci?","commit_id":"5990d2f1ec4e9af315dcd93dc925e6af71eeb8ce"}],"neutron_lib/db/api.py":[{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"6ee6b6e58e2b656e1c004b9b973c4b97d9286f8f","unresolved":true,"context_lines":[{"line_number":49,"context_line":"    if _CTX_MANAGER is None:"},{"line_number":50,"context_line":"        _CTX_MANAGER \u003d enginefacade.transaction_context()"},{"line_number":51,"context_line":"        _CTX_MANAGER.configure(sqlite_fk\u003dTrue, flush_on_subtransaction\u003dTrue,"},{"line_number":52,"context_line":"                               synchronous_reader\u003dFalse)"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"    return _CTX_MANAGER"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"35aeca4c_f707554e","line":52,"updated":"2025-03-24 21:11:58.000000000","message":"One I wanted to check with you is, should we have a configuration parameter for this?\nIf yes, do you think this should be in neutron scope, or oslo-db scope?","commit_id":"5990d2f1ec4e9af315dcd93dc925e6af71eeb8ce"},{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"4a91200cb0c8eb83c7155778d52c3f79ff31fa67","unresolved":true,"context_lines":[{"line_number":49,"context_line":"    if _CTX_MANAGER is None:"},{"line_number":50,"context_line":"        _CTX_MANAGER \u003d enginefacade.transaction_context()"},{"line_number":51,"context_line":"        _CTX_MANAGER.configure(sqlite_fk\u003dTrue, flush_on_subtransaction\u003dTrue,"},{"line_number":52,"context_line":"                               synchronous_reader\u003dFalse)"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"    return _CTX_MANAGER"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"2828dea7_824b802c","line":52,"in_reply_to":"35aeca4c_f707554e","updated":"2025-03-25 14:56:02.000000000","message":"We cannot set this as a default because we cannot make assumptions on the backend somebody uses, see the comment in your other patch for oslo.db [1] of which I think it should actually be configurable but as an end-user/operator knowing if it actually works for a projects codebase is hard.\n\nConsider something like this:\n```\ndef create_port():\n    with sql_for_writer():\n        return db.create_port(...)\n\ndef get_port(id):\n    with sql_for_reader():\n        return db.get_port(id)\n\ndef give_me_a_port():\n    port \u003d create_port()\n    new_port \u003d get_port(port.id)\n    return new_port\n```\n\nIf write hits database_connection and read hits slave_connection there can be enough replication lag in the database so you cannot read the port you\u0027ve just created, so either the developers or the end users really needs to be super aware that the use-case is tested for such race conditions, thus there is the async_reader in oslo.db that is exclusively for this.\n\nWe had the same idea as you when we did a migration with the database that backed our Keystone, we basically did what you do here [2] (after feedback from Mike) to force the use (for everything) of slave_connection but were using a **read-only** MySQL user during the migration, when I browsed the code for Keystone there were multiple places where such a race condition were possible so we could not assume that just because a reader is used it\u0027s allowed to be a **async** reader.\n\n[1] https://review.opendev.org/c/openstack/oslo.db/+/945415\n[2] https://review.opendev.org/c/openstack/keystone/+/926776","commit_id":"5990d2f1ec4e9af315dcd93dc925e6af71eeb8ce"}]}
