I like (2) best. And IMO we don't need to do it until necessary. I agree it could be "interesting", OTOH it may be super simple. Once the state.json file is re-read it may all just be OK.
For (3) I'd need to see a compelling use-case, I'd hate to try to debug the problems from messing up the pattern. I suppose we could barf if, say, they had already used the name for anything in the collection so maybe it wouldn't be too bad. But I don't think I'd like to do anything on that up front. And I think we actually _do_ allow replica naming if you ADDREPLICA with a property.name=whatever. But I so don't want to deal with the ramifications that I'm not even going to try it to see. ;) Erick On Wed, May 31, 2017 at 10:30 AM, Tomas Fernandez Lobbe <tflo...@apple.com> wrote: > Thanks for the summary Erick. I’m also in favor of leaving the type as part > of the name. In the future if we provide the option of changing the type of a > replica I can see three options: > 1) We do nothing with the name. The user who does replica type changes will > have to know that this character is meaningless for them. Not the best > option, specially if we provide an automated way to change the type. > 2) We change the name of the replica to reflect the new type. May not be too > easy, not sure how other parts of Solr will react to this, but may be the > best approach. > 3) We provide a way for users to define their own naming scheme for replicas > (I’m thinking something like log4j logging pattern). Not sure if this will be > needed really, it depends on how internal we consider the replica naming to > be. > > Tomás > >> On May 30, 2017, at 10:32 AM, Erick Erickson <erickerick...@gmail.com> wrote: >> >> 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 >> > > > --------------------------------------------------------------------- > 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
