[ https://issues.apache.org/jira/browse/SOLR-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105095#comment-15105095 ]
Shai Erera commented on SOLR-8561: ---------------------------------- I thought that it should, but didn't for two reasons: 1) On the original issue where this issue was introduced (SOLR-7844), writing the leader props to both "shard1" and "shard1/leader" was done in 5x only, suggesting that there was no intention for 6.0 to be backward compatible with 5.x in this regard. 2) [~markrmil...@gmail.com] made this comment "Yeah, 5x needs a little bridge back compat that checks the old location if the new one does not exist." which again, made me think that there was no intention to support such a use case. Basically I agree with you, if someone will upgrade from 5.3 straight to 6.0, and will want to do this as a rolling upgrade, then he'll hit that issue. But I wasn't sure if that scenario is intended to be supported. I'd be happy to port this fix to trunk as well if people think otherwise. > Add fallback to ZkController.getLeaderProps for a mixed 5.4-pre-5.4 > deployments > ------------------------------------------------------------------------------- > > Key: SOLR-8561 > URL: https://issues.apache.org/jira/browse/SOLR-8561 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Reporter: Shai Erera > Assignee: Shai Erera > Fix For: 5.5, 5.4.1 > > Attachments: SOLR-8561.patch, SOLR-8561.patch > > > See last comments in SOLR-7844. The latter changed the structure of the > leader path in ZK such that upgrading from pre-5.4 to 5.4 is impossible, > unless all nodes are taken down. This issue adds a fallback logic to look for > the leader properties on the old ZK node, as discussed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org