MohammadYusif commented on PR #37: URL: https://github.com/apache/solr-orbit/pull/37#issuecomment-4563474399
**Client-layer primitives** — `create_collection`, `delete_collection`, etc. — are pure infrastructure operations. The caller just wants the resource to exist or not; they don't care which API path was used. Here, transparent fallback is correct because the semantics are identical. That's what this PR does, and it's the right call for this narrow case. **Workload-level features** — multi-shard/replica topology, `splitshard`, the SolrCloud backup API — have *no meaningful standalone equivalent*. A fallback here would silently change what's being benchmarked, which is worse than failing. For these, workloads should **declare their requirements** and orbit should **fail fast** with a clear error message before any work begins. Concretely I'd suggest something like a `requires_cloud: true` field in the workload spec (or an `incompatible_modes` list), validated at startup against the detected deployment mode. The detection itself can reuse the same "is this ZooKeeper-aware?" signal this PR already handles. So: **keep this PR's fallback**, it's appropriate here. But the broader policy should be: transparent fallback only where semantics are genuinely equivalent; declared incompatibility + early exit for everything else. That's unambiguous to workload authors and to users trying to understand why a run failed. -- 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]
