Tomás: Thought that might be the case. I'm not opposed to the naming change as long as it serves a purpose as this one does. People shouldn't write scripts that assume hard-coded names anyway ;).
Ishan: I give long odds that we _will_ need the capability to reassign replica roles. One of the points of this work is that people need to fine-tune how nodes on the cluster are utilized, which I'd imagine means reassigning replica functions. All: I rather like that the node name gives us information about the role. having to go to the state.json file to find some other property is onerous, especially in very large installations. Proposal: Let's keep the naming convention with the n, t, and p notation. If in the future we want to reassign a replica's role we can rename the node when its role changes. On Tue, May 30, 2017 at 10:12 AM, Ishan Chattopadhyaya <ichattopadhy...@gmail.com> wrote: > Do we shut ourselves out of the possibility to ever re-assigning the replica > types, by using this naming convention? > For example, is there any conceivable scenario in future whereby an NRT > replica can become a TLOG replica? > Never mind my asking if this flexibility is something we're sure we'll never > need. > > On Tue, May 30, 2017 at 9:49 PM, Tomas Fernandez Lobbe <tflo...@apple.com> > wrote: >> >> Hi Erick, >> This change is part of replica types. I mentioned this in SOLR-10233, but >> you are right, I should have mentioned probably in the dev list to get to >> more people. The last character represents the type of replica (n->NRT, >> t->TLOG, p->PULL). This is certainly not required and can be reverted back >> if people has concerns. I found it very useful when developing and I think >> it will also be helpful in prod, since the replica name is present in most >> log entries (since the MDC logging changes). >> >> Tomás >> >> > On May 30, 2017, at 8:54 AM, Erick Erickson <erickerick...@gmail.com> >> > wrote: >> > >> > I noticed recently that our replica names are changing (master only?) >> > to collection_shard1_replica_n1. Why? >> > >> > Mostly I wan to be sure we consider whether this change is worth the >> > confusion before it gets out into the wild. If it's just an aesthetic >> > change I question whether it's worth the confusion it'll generate. If >> > it serves a real purpose, that's another story.. >> > >> > Erick >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
