)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"b101c9936bf2585789d065a54a2ab41a834acb3c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"97b270b8_9e25d077","updated":"2024-10-30 11:33:05.000000000","message":"Just to be sure, is your environment is monkey patched or not?\n\nBecause, as you well stated in your commit message, if the executor is not passed to the oslo.messaging `get_rpc_server` method, then oslo.messaging will try to automatically retrieve the right executor based on a check against your environment (is your env is monkey patched or not?), so if your env is patched (at least the threading module), then, you will continue to use the eventlet executor even if you removed the executor parameter (only if the threading module is monkey patched).\n\nIf the executor parameter is explicitly set to \"threading\" then the threading executor will be used but if your env is monkey patched in this case we fall into greenlet considerations like those described here https://greenlet.readthedocs.io/en/stable/python_threads.html I don\u0027t know how far it could impact you in your scenario, but this is a point that we should not ignore. I don\u0027t know if not monkey patching the threading module from eventlet is enough to remains safe or if we still fall in the deep mechanisms of greenlet. \n\nPlease see the discussion here https://review.opendev.org/c/openstack/oslo.messaging/+/933399/comments/8b199129_917fda64","commit_id":"9840db16249397569e5705a4f25a804a90ec225d"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"469f26ec2a0c622f29c87e10191799cbbabc5c7f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5aee27ba_01c44ea2","updated":"2024-09-30 10:09:02.000000000","message":"Probably we can deprecate that argument in oslo.messaging to reduce complexity...","commit_id":"9840db16249397569e5705a4f25a804a90ec225d"},{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"c84b027dfa67f6061cfc170e101109c284d2b06a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0a9bf186_a2c5449f","in_reply_to":"97b270b8_9e25d077","updated":"2024-10-30 11:58:32.000000000","message":"I mean, using eventlet in your components probably also mean that you are using greenlet mechanisms to manage tasks etc, so, if in the same component you use a mix between greenlet coroutines and native threads, then we chance to face the same scenario that the one described in the greenlet doc https://greenlet.readthedocs.io/en/stable/python_threads.html Even if eventlet do not monkey patch the threading module.\n\nEventlet monkey patch things to make them ready for async network IO, but we should not forget that even without monkey patching specific stdlib modules, greenlet is lurking behind Eventlet exposing us to its internal mechanisms. So if your application use greenlet root mechanism through Eventlet I think we are exposed in some ways.","commit_id":"9840db16249397569e5705a4f25a804a90ec225d"}]}