serhiy-bzhezytskyy opened a new issue, #79:
URL: https://github.com/apache/solr-orbit/issues/79
### Description
A converted workload aborts on the task that waits for merges to finish.
OpenSearch
Benchmark has no operation type for that wait — workloads express it as an
`index-stats`
call retried until the active merge count reaches zero:
```json
{
"name": "wait-until-merges-finish",
"operation-type": "index-stats",
"index": "_all",
"condition": { "path": "_all.total.merges.current", "expected-value": 0 },
"retry-until-success": true,
"include-in-reporting": false
}
```
The converter copies `"operation-type": "index-stats"` through unchanged,
and no runner is
registered for it, so `runner_for` raises and the run stops.
Solr Orbit already has the operation this is meant to be: `wait-for-merges`,
registered
since the initial port (`57387ed4`), whose runner polls node metrics in its
own loop. The
hand-written Solr `nyc_taxis` in `solr-orbit-workloads` uses it. So this is
not a missing
feature — the converter simply does not reach for it.
### To reproduce
On `main` at f0883807, convert upstream `nyc_taxis` and run that task on its
own against
the default test procedure:
```
solr-orbit run --workload-path <converted>/nyc_taxis
--pipeline=benchmark-only \
--target-hosts=localhost:8983 --include-tasks=wait-until-merges-finish
```
```
[ERROR] ❌ Cannot run. Benchmark operation failed:
Worker ID: 0
Task: wait-until-merges-finish
Workload: nyc_taxis
Test Procedure: append-no-conflicts
Cause: Unknown
Error: No runner available for operation type [index-stats]
No runner available for operation type [index-stats]
```
Exit code 64.
### Expected behavior
An `index-stats` operation whose condition polls the merge count to zero
should be
converted to `wait-for-merges`, with the polling OpenSearch expresses
through `condition`
and `retry-until-success` carried by the runner's own `retry-wait-period` and
`max-wait-seconds`.
The hand-written Solr `nyc_taxis` in `solr-orbit-workloads` already states
the intended
result, so there is a target to compare against:
```json
{
"name": "wait-until-merges-finish",
"operation-type": "wait-for-merges",
"retry-wait-period": 2.0,
"max-wait-seconds": 600,
"include-in-reporting": false
}
```
### Additional context
In the default test procedure the merge wait arrives through
`common_operations/force_merge.json`, which is collected after `index` and
`refresh-after-index` — so a full converted `nyc_taxis` run fails only once
the corpus is
indexed and merged. The expensive part is already spent when it aborts.
It is not specific to `nyc_taxis`. Because the idiom lives in that shared
fragment, it
reaches the converted output of `clickbench`, `geoshape`, `http_logs`,
`neural_search`,
`nyc_taxis`, `pmc` and `treccovid_semantic_search` — 16 operation
definitions across 13
generated files, all of them this idiom.
A 17th match in `geonames/test_procedures/default.json` is a different thing
and not part of
this report: `"operation": "index-stats"` there is a schedule reference to
OpenSearch
Benchmark's built-in operation of that name, which the workload never
defines. It also has no
Solr runner, but the fix is not the same one.
Two further source occurrences are out of reach for a third reason —
`clickbench/test_procedures/common/snapshot-ops.json` and
`noaa_semantic_search/test_procedures/semantic-search-common/check-status-add-resources-no-index.json`
sit in nested directories under `test_procedures/`, and the converter only
walks the
top-level `.json` files there, so those files are absent from the output
entirely. That is a
separate defect; I will report it on its own.
### Version
`main` at f0883807.
--
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]
