patsonluk commented on PR #1143: URL: https://github.com/apache/solr/pull/1143#issuecomment-1481678376
> How does this interact with the `genericCoreNodeNames` option in [the solr.xml](https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solrcloud-element)? It seems like that is made so that cores can be moved between nodes... Thank you for the raising the concern @HoustonPutman , I was not aware of such option! From my brief search the reference on `ZkController#genericCoreNodeNames`/`cloudConfig.getGenericCoreNodeNames()`, it only appears to affect the result of `getCoreNodeName`. So I assume the `Replica#getNodeName` (read from the state.json, which `genericCoreNodeNames` should not matter?) would still be a mismatch to the `ZkController#getNodeName`. However, ur concern does lead me to think deeper on several scenarios, which I think would be great if you can provide some insights: 1. From `genericCoreNodeNames`, it mentions the case of `When a different machine takes over serving that core things will be much easier to understand.`. I assume all replica modes should be done via admin APIs (ie MOVESHARD/REPLACENODE) etc, which should update the state.json accordingly. Do we support some other forms of moves? like physically moving the folders around and expect Solr to detect the change and "self correct" the state.json? My approach assumes that if state.json is incorrect, we should not attempt to self-correct it, but I could have misunderstood some of the designs 😓 2. What about node name changes on a host? For example if we used to pass IP as `-Dhost` but now with the hostname, should we assume that Solr would start up fine and state.json will be "self-corrected"? -- 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]
