Actions
Bug #46257
closedFAIL: s3tests_boto3.functional.test_s3select
% Done:
0%
Source:
Q/A
Tags:
s3select
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Description
====================================================================== FAIL: s3tests_boto3.functional.test_s3select.test_csv_definition ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ubuntu/cephtest/s3-tests/virtualenv/lib/python3.6/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/home/ubuntu/cephtest/s3-tests/s3tests_boto3/functional/test_s3select.py", line 382, in test_csv_definition nose.tools.assert_equal( number_of_rows, int(res)) AssertionError: 10000 != 10030 -------------------- >> begin captured logging << --------------------
Updated by Gal Salomon almost 4 years ago
- the issue easily reproduce (single OSD/RGW , 2 clients)
- it seems to relate to spirit parser, should be check for its thread safety (not sure BOOST_SPIRIT_THREADSAFE is enougth).
- this issue by itself cause random failure
Updated by Gal Salomon almost 4 years ago
- Status changed from New to In Progress
Updated by Gal Salomon almost 4 years ago
- the syntax-parser is currently NOT thread-safe
- per parser-rule been accepted, a bind-function-object in which builds the AST (abstract syntax tree), is executed.
- that function-object responsible for using the correct s3select-request-context.
- each s3select-requests has different heap allocation per its AST.
- that heap-allocation(structure contains a s3select-context) is override by other s3select-request, resulting a failure.
Updated by Gal Salomon almost 4 years ago
- the test_s3select , should use unique names per objects. on parallel run it may cause failure.
- s3select-engine should maintain per-thread-context
Updated by Gal Salomon almost 4 years ago
- Subject changed from FAIL: s3tests_boto3.functional.test_s3select.test_csv_definition to FAIL: s3tests_boto3.functional.test_s3select
- Pull request ID set to 12
Updated by Casey Bodley over 3 years ago
it looks like we'll need a ceph PR that updates the s3select submodule, and reenables the s3select testing
Updated by Casey Bodley over 3 years ago
- Status changed from In Progress to Resolved
Updated by Casey Bodley over 3 years ago
- Status changed from Resolved to In Progress
this was fixed in https://github.com/ceph/s3select/pull/14, but the ceph submodule was never updated to include these changes, and s3test coverage of s3select is still disabled in https://github.com/ceph/ceph/blob/master/qa/tasks/s3tests.py#L335
the s3select submodule was updated since, and s3test is not disabled.
Updated by Casey Bodley over 2 years ago
- Status changed from In Progress to Resolved
Actions