Re: Replica naming changed.

[Erick Erickson <er...@gmail.com>]

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
<tf...@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 <er...@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
>> <ic...@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 <tf...@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 <er...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org