On 9/20/2018 8:59 AM, Shawn Heisey wrote:
I just completed a test where I did that exact sequence of converting
a node from non-cloud with existing indexes to cloud, and ran into the
exact same errors you're seeing. I can relay exact details of the
test if required.
Here's what I did to replicate the symptoms. On a Windows 10 system, I
did this in the root of an extracted 7.3.0 download:
bin\solr start -e cloud -noprompt
This starts up a two-node SolrCloud example, all on one machine, with an
embedded ZooKeeper running in the first node.
Then I did this:
bin\solr create -c foo -p 8983
This created a collection called foo within the cloud. So far, no problems.
Then I did this, to start up another instance, this time non-clouid.
bin\solr start -p 8900
That was followed by this command to create a core called foo in the
non-cloud instance:
bin\solr create -c foo -p 8900
Then I stopped the non-cloud instance, and started it again as a cloud
instance, pointing at the existing zookeeper:
bin\solr stop -p 8900
bin\solr start -p 8900 -z localhost:9983
At this point, when visiting http://localhost:8900 to see the admin UI,
it will complain about not being able to start the core named foo, and
the log will show the same errors you sent. The instanceDir is not under
configsets ... I was not using the configsets feature in the non-cloud
install. If the name of the core does not match the name of an existing
collection in the cloud install, then the errors are different. In your
case, the core name does match the name of a collection in your cloud.
Thanks,
Shawn
