Andrzej Bialecki created SOLR-14122:
---------------------------------------
Summary: SimUtils incorrectly converts v2 to v1 request params
Key: SOLR-14122
URL: https://issues.apache.org/jira/browse/SOLR-14122
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.3
Reporter: Andrzej Bialecki
Assignee: Andrzej Bialecki
Fix For: 8.5
As reported by Li Cao on the mailing list:
{quote}I am using solr 8.3.0 in cloud mode. I have collection level autoscaling
policy and the collection name is “entity”. But when I run autoscaling
simulation all the steps failed with this message:
"error":{
"exception":"java.io.IOException:
java.util.concurrent.ExecutionException: org.apache.solr.common.SolrException:
org.apache.solr.common.SolrException: Could not find collection :
entity/shards",
"suggestion":{
"type":"repair",
"operation":{
"method":"POST",
"path":"/c/entity/shards",
"command":{"add-replica":{
"shard":"shard2",
"node":"my_node:8983_solr",
"type":"TLOG"}}}},
"replicaInfo":null}}},{quote}
The simulation package internally uses v1 APIs but the requests created by the
autoscaling framework may use v2 APIs. The utility class {{SimUtils}} converts
v2 request parameters to v1 parameters, without actually using the apispec or
v2 Api handlers (as that would mean adding more complexity to the simulator,
and only tangentially related to the autoscaling).
There's a bug in this utility when converting the path of the request - V2
apispec uses {{/c/\{collection}/shards}} when manipulating shards and replicas
- unlike V1 which uniformly uses {{/collections}}. The utility class doesn't
account for this path difference and creates invalid collection names.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
