janhoy opened a new pull request, #105: URL: https://github.com/apache/solr-orbit/pull/105
### Description The `it/` suite could not run a single test, and no workflow exercises it, so it had quietly rotted into a pile of OpenSearch leftovers and stale pins. Each of these failed before any test body ran. **Test-suite repairs** - `setup_module` started a `MetricsStore` pinned to `"1.3.9"`, an OpenSearch version that `--distribution-version` rejects (minimum 9.0.0), so every test in the package errored with `Failed to install node 1.3.9`. The cluster was never used — it is inherited from OpenSearch Benchmark, where metrics live in an OpenSearch cluster, whereas Solr Orbit keeps them on the local filesystem; the only integration config sets `datastore.type = in-memory` and nothing reads `datastore.host` or its port 10200. Removed rather than repointed, since bumping the version would download and run a Solr nobody talks to before every test. - `DISTRIBUTIONS` pinned Solr **10.1.0, which was never released**. Now `9.11.0` and `10.0.0`, both of which `downloads.apache.org` actually carries (it keeps only current releases, so anything older comes from the much slower archive). - `list_test` pinned workloads revision `cba4e45dda…`, which no longer exists — GitHub returns 422. Now the workloads repository's initial commit, which cannot disappear short of a history rewrite. - `sources_test` passed `--opensearch-plugins=analysis-icu`, an unrecognized argument (exit 2). Now `--solr-modules=analysis-extras`, where Solr keeps the ICU analysis components, so the test keeps its original intent of building from source with an extra module enabled. - `TestCluster.start` passed `--runtime-jdk="bundled"`, an OpenSearch notion — its distributions ship a JDK, Solr's do not — which resolved to a nonexistent `JAVAbundled_HOME`. Now `21`: left to itself the resolver picks the lowest allowed JDK, 11, which cannot start Solr 10. - `TestCluster.start` called `client.wait_for_rest_layer`, which does not exist. `SolrClient` carries its own `wait_for_cluster_ready`. - `tracker_test`'s fixture leaked a running Solr node when `start()` failed, and that node then held the port against every later test. **And the one that matters most:** `BASE_COMMANDS` invoked a bare `"solr-orbit"`, which resolves to whatever is on `PATH` — here a pyenv shim for a globally installed copy. The integration tests were exercising an installation with no relation to the working tree. They now invoke `sys.executable -m solrorbit.benchmark`. **Product fixes** These are needed because the tests must not assume port 8983 — a Solr developer very likely has their own Solr there, and the provisioning pipelines refuse to start when the port is busy. - `NodeConfiguration` now carries `http_port`, and both launchers pass it to `bin/solr` and export `SOLR_PORT`. Previously `--http-port` was accepted and recorded but never reached the node, which always bound 8983: `SOLR_PORT` was read with a default and set nowhere. `from_dict` tolerates a `node-config.json` written before the field existed. - A new `--solr-port` flag feeds `solr.port`, which had a default and **no setter at all**, so the `docker`, `from-distribution` and `from-sources` pipelines were pinned to 8983. The integration tests now bind a random free port. - The unused-workload-parameter error read `"… are not used by this workload; perhaps you intend to use instead."` whenever no close match existed. The suggestion clause is now included only when there is something to suggest, and `info_test` uses a typo that actually has a close match, so it covers that path instead of asserting a suggestion for a parameter `geonames` no longer exposes. ### Issues Resolved Closes #103 ### Testing `make lint` clean; `make test` passes (1132 passed, 5 skipped). `info_test`, `list_test`, `download_test` and `proxy_test` go from **8 errors to 12 passed**: ``` before: 8 errors in 0.72s after: 12 passed ``` I could not get the cluster-provisioning tests (`distribution_test`, `sources_test`, `tracker_test`) green locally, and I want to be explicit about why rather than imply the suite is fully verified. Two macOS-specific hangs block them on my machine, both outside this change: - The CPython `os.stat` → `fill_time` → `_PyLong_Multiply` recursion during corpus download. Reproduced on Python 3.12.11; `sample` shows the stack, 0 bytes written in 20 minutes. - A Thespian stall. `socket.getfqdn()` returns `1.0.0.0.…0.ip6.arpa` here, so `getaddrinfo()` fails and `Unable to get address info` is logged. Forcing `multiprocQueueBase` removes that warning but the run still hangs, so there are two independent causes. This is the same failure OpenSearch Benchmark closed by removing macOS from its supported platforms. What I did verify on those paths: Solr 9.11.0 downloads, installs and starts on a random port (`-Djetty.port=54072`), which exercises the `--solr-port` and `NodeConfiguration.http_port` changes end to end. I will file two follow-ups: one for the Thespian situation, and one to run `it/` in CI on Linux — which would have caught every item in this PR and would sidestep the macOS blocker. 🤖 Assisted by Claude Code -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
