)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4d765f62fa372d3deec72c6ae8ac27496fe85388","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d210e0f4_7b584ae2","updated":"2024-06-05 16:08:00.000000000","message":"looks good to me.","commit_id":"50ae07a1beb66d89f581ba1e9707dd3b99b26e1c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"71a1757ef6254c306ee27e722a7799f586a446b4","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2a29e078_b0171ee2","in_reply_to":"1dfb6ae6_063d00c2","updated":"2024-06-11 22:21:26.000000000","message":"i think gibi is correct.\n\nby default we schdule the test between worksres on the class level as far as i am aware os all test in a given classs would normmlay go to one  worker.\n\nif they were split between workers then the class setup which runs once per class per python process woudl still serialise the execution between workers.\n\nsince each worker only executes one test at a time we in effect ensure only one test shoudl execute at a tiem even if its locked at the class less.\n\nthe only beifeit to doing the locking at the test level would perhaps be a slighly fair locking since between serial and non serial test.\n\nhowever since we actully distibute test between workser in  a dterminstic mander (bases on teh lexegrapcial sortiing of the tests) all of the in tree serial tess run after everything else because tempest.serial happens to be afater every other test directory.\n\nso i think this change is not needed.","commit_id":"50ae07a1beb66d89f581ba1e9707dd3b99b26e1c"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"9a02d9d357ffd7f2efb09d84e36dc11316eab1f3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"1dfb6ae6_063d00c2","in_reply_to":"cecdb8b0_b43e7363","updated":"2024-06-06 15:16:06.000000000","message":"This is ignorance on my part on how Tempest executes test cases, but isn\u0027t it possible that once the lock is acquired for the class, the test cases inside that class are executed in parallel? Or is parallelism in Tempest only achieved by running multiple runners, and each runner executes test cases serially, executing the class setUpClass/tearDownClass once for every test case?","commit_id":"50ae07a1beb66d89f581ba1e9707dd3b99b26e1c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"afc27f785b4789a839c0a610cae23ce45c3d8e36","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cecdb8b0_b43e7363","in_reply_to":"d210e0f4_7b584ae2","updated":"2024-06-06 07:16:02.000000000","message":"I changed my mind. I think we don\u0027t necessary need this.\nYes the lock is taken on the class level. But it should not cause any parallel run. Imagine that you have two tempest worker processes running the test cases. As they are processes they only share the lock via the filesystem path, and no other state is shared between them.\n\n1. Now worker 1 wants to execute a test case in a serialized class. As this is the first test executed from that task by this executor the setupClass runs and try to take the write lock. Let\u0027s assume that nothing else is holding the lock so it can take it.\n\n2. Now worker 2 also wants to execute a test from the same serialized class. As this is the first test executed from that class in this executore setupClass runs ans tries to take the lock, but it cannot.\n\nIn general an executor can only execute a serialized test case if it run the setupClass and therefore taken the lock. Also an executor will not run teardownClass while running a test case. So the current logic ensures serialization between executors. The only thing this patch changes is the granularity of the taking and releasing the lock which could be an optimization. However it might cause troubles as it would allow two setupClass execution to overlap as setupClass runs before setUp. So if setupClass actually manipulate openstack then that can be a problem.","commit_id":"50ae07a1beb66d89f581ba1e9707dd3b99b26e1c"}]}