A script, rocksdb_logtool.py, is available to upload/download generated
XML/JSON log files when test harness 2 detects that the test is failed,
and the script detects that the test is using RocksDB.
To upload, no actions is needed, using the regular
```
joshua start --tarball correctness.tgz
```
The build system will automatically pack the rocksdb_logtool.py into the
tarball and test harness 2 will call the script if it thinks the test is
failed.
To download, simply provide the ensemble id and test uid, e.g.
```
python3 rocksdb_logtool.py download --ensemble-id
20230222-204240-xiaogesu-cb6ea277a898f134 --test-uid
ab6fb792-088f-49d6-92d2-43bc4fb81668
```
Note the test UID can be retrieved by
```
joshua tail ensemble_id
```
output, it is in the field `TestUID` in <Test> element of test harness 2
generated XML.
For convenience, it is possible to do a
```
python3 rocksdb_logtool.py list --ensemble-id ensemble-id
```
to generate all possible download commands for failed tests. However,
the list subcommand will *NOT* verify if the test failure is coming from
RocksDB, i.e. other test failues may be included and it is the caller's
responsibility to verify. If the test is not RocksDB related, the
download would fail as nothing is uploaded.
* get_client_status: add to Java bindings
* Add get_client_status in python binding
* Make python unit tests available as ctest
* Fix file name in the copyright header
* Fix library path name for mac
* get_client_status: Minor changes in Java & Python bindings addressing review comments
* Rename fdb_python_unit_tests to unit_tests
bindingtester2-${FDB_VERSION} is generated in packages/ directory.
It is possible to run the test by
j start --tarball bindingtester2-7.3.0.tar.gz --max-runs 1000
and submit the test to joshua system. Joshua will run the tests in
parallel and tests will not impact each other. Yet it will take long
time for each run.
Add atomic op functions to the tenant object in Python.
Fix a Python tester bug for tenant operations.
Fix a build error with the binding tester package.
* Auto-formatting fdb_c_shim_tests.py
* Define the old release versions used for testing in one place; Using PYTHONPATH to find python modules from other project directories
* Remove obsolete upgrade tests; add direct upgrade tests from older versions
* Trigger tests
* Add a cmake option ENABLE_LONG_RUNNING_TESTS to generate separate correctness package for long running tests
* Remove the unnessary long_running_tests directory
* Use the default bash files
* Fix the RocksDB compile issue with clang
By default, RocksDB is using its own compile/link flags, no matter how
FDB flags are. This led to the issue that if FDB decides to use
clang/ldd/libc++, RocksDB will pick up the compiler/linker but still use
libstdc++, which is incompatible to libc++, causing Symobl Missing error
during the link stage.
With this patch, if FDB uses libc++, then the information is stored in
CMAKE_CXX_FLAGS and being forwarded to RocksDB. RocksDB will then use
libc++ and compatible with FDB.
* fixup! update the indentation
With aarch64, in the current docker image, linking curl statically doesn't work yet.
This is the diagnostic:
```
fdbclient/awssdk-build/curl/lib/strerror.c:32:6: error: #error "strerror_r MUST be either POSIX, glibc or vxworks-style"
2022-09-22 16:05:30 # error "strerror_r MUST be either POSIX, glibc or vxworks-style"
2022-09-22 16:05:30 ^~~~~
```
The root cause is that curl's cmake feature detection logic gets
confused since it can't build binaries that execute successfully with
the link flags it wants:
```
$ cc test.c -lssl
$ ./a.out
./a.out: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
```
Markus Pilman