Fix PyLucene sidecar packaging and add smoke tests#174
Conversation
and finish updating cuvs version
Convert the PyLucene smoke runner to a pytest-backed case matrix covering GPU CAGRA search, CAGRA-built HNSW, and forced CPU HNSW fallback across segment and force-merge topologies. Add named one-layer and three-layer CAGRA-to-HNSW codecs plus writer-path telemetry so the e2e suite can assert which CPU/GPU path was exercised. Tighten sidecar and Lucene delegate-codec validation to avoid misleading expected probe warnings while still failing on unsupported delegate codecs.
| @Override | ||
| public KnnVectorsWriter fieldsWriter(SegmentWriteState state) throws IOException { | ||
| var flatWriter = FLAT_VECTORS_FORMAT.fieldsWriter(state); | ||
| System.setProperty( |
There was a problem hiding this comment.
These System.setProperty methods make sense in the context of this PR as a way to communicate between the Java and Python layers. However, they introduce unnecessary overhead for most other applications. Moreover, this approach would not work reliably in a multithreaded environment, since the same property is reused across requests. I think it would be better to separate the telemetry concerns and extract them into a dedicated method that is invoked only when telemetry data is actually needed.
There was a problem hiding this comment.
Good point! Removed the JVM-global system properties from the indexing path. Telemetry is now computed on demand from the vectors format only when the PyLucene test requests it.
| To run the PyLucene pytest smoke suite against a local PyLucene environment: | ||
|
|
||
| ```sh | ||
| ./ci/test_pylucene_smoke.sh |
There was a problem hiding this comment.
I like that we have ci scripts for this , but a user should not have to invoke ci scripts in order to run tests. Rather, we should document how to run these pytests without the need to call scripts inside the CI directory while also providing the scripts in the CI directory for GitHub actions to run automatically.
There was a problem hiding this comment.
@cjnolet I moved the user-facing logic to test_pylucene.sh and kept a thin wrapper under ci/. The current GitHub Actions workflows do not invoke it yet. Did you intend for this PR to add a PyLucene Actions job as well, or is providing the CI entry-point sufficient for now?
| ./ci/test_pylucene_smoke.sh --gpu-e2e | ||
| ``` | ||
|
|
||
| The expanded suite runs the `gpu-basic`, `gpu-segments`, `cpu-hnsw`, and |
There was a problem hiding this comment.
Great description here. How to build and run tests should really be in a separate build and install guide. I think this is okay for now, especially since we are moving cuVS-Lucene to cuVS, but it's something to consider.
| .withCagraGraphBuildAlgo(CagraGraphBuildAlgo.NN_DESCENT) | ||
| .withGraphDegree(CAGRA_GRAPH_DEGREE) | ||
| .withIntermediateGraphDegree(CAGRA_INTERMEDIATE_GRAPH_DEGREE) | ||
| .withHNSWLayer(1) |
There was a problem hiding this comment.
Wasn't this an issue that you resolved? Why layer 1?
There was a problem hiding this comment.
Yes, that issue was resolved. Layer 1 is intentional test coverage, paired with the three-layer case -- that said, I am not sure that these two particular tests will provide much utility
Summary
This PR fixes the PyLucene sidecar packaging and expands the PyLucene smoke coverage into a pytest-backed CPU/GPU end-to-end suite.
The sidecar jar now keeps PyLucene responsible for Lucene classes while cuvs-lucene contributes only its own classes and service providers. The smoke wrapper validates that layout before running the Python tests, so packaging regressions fail early with a clear message.
The expanded PyLucene suite covers the main index/search paths we expect users to exercise:
The expanded suite prints the path exercised by each case, such as
path=gpu-cagra,path=gpu-hnsw, orpath=cpu-hnsw-fallback, so the test output makes it clear whether each case used the intended CPU or GPU path.Notable Changes
--cases,--rows,--dims, and--topkoptions toci/test_pylucene_smoke.sh.Running the Suite
From a PyLucene environment on a GPU machine, the standard full run is:
That command builds the cuvs-lucene sidecar jar when needed, locates the base
cuvs-javajar, validates the sidecar contents, sets the required environment variables, and then runs the pytest suite.If the sidecar jar has already been built, the same suite can be run without rebuilding:
With
--no-build, the wrapper expects an existing sidecar jar undertarget/or viaCUVS_LUCENE_PYLUCENE_JAR. It does not build a missing jar.After setup, the wrapper invokes:
pytestmust be installed in the active PyLucene Python environment.Validation
Validated on a
g5.2xlargeEC2 instance with NVIDIA A10G:./ci/test_pylucene_smoke.sh --gpu-e2e --cases=all --no-buildAlso checked locally:
bash -n ci/test_pylucene_smoke.shgit diff --checkLocal Maven validation was not run in this Codex workspace because
mvnis not installed here.