Thanks.

But since the docs are incorrect as far as current behavior is
concerned, I'll change the info on the CWiki to reflect the current
state of affairs.

I just did a brief test with creating a collection with legacyCloud
set to false and no change.

Erick

On Thu, Sep 4, 2014 at 12:06 PM, Shalin Shekhar Mangar
<shalinman...@gmail.com> wrote:
> Yeah, this all feedbacks into the ZK as Truth mode that we've been talking
> about. The documentation is misleading because yes, if a node comes back
> up, then it will add itself to the cluster state. There are plans to change
> that behaviour once we've thought through more use-cases and are ready to
> break back-compat. There is a new cluster level property called
> "legacyCloud" which defaults to "true" but if it is set to "false" then
> behaviour documented on the reference guide will be used.
>
>
> On Wed, Sep 3, 2014 at 6:01 PM, Erick Erickson <erickerick...@gmail.com>
> wrote:
>
>> I'm confused, wondering if it's a mismatch between the docs and the
>> intent or just a bug or whether I'm just not understanding the point:
>>
>> The DELETEREPLICA docs say:
>>
>> "Delete a replica from a given collection and shard. If the
>> corresponding core is up and running the core is unloaded and the
>> entry is removed from the clusterstate. If the node/core is down, the
>> entry is taken off the clusterstate and if the core comes up later it
>> is automatically unregistered."
>>
>> However, if I do the following:
>> 1> create a follower on nodeX
>> 2> shut down nodeX (at this point, the clusterstate has indicates the
>> follower is down)
>> 3> issue a DELETEREPLICA for the follower (clusterstate entry for this
>> follower is removed)
>> 4> restart nodeX (clusterstate shows this node is back, it's visible
>> in cloud veiw, gets sync'd etc.).
>>
>> Based on the docs, I didn't expect to see the node present in step 4,
>> what am I missing?
>>
>> The core has docs (i.e. it's synched from the leader) etc. So this bit
>> of the documentation is confusing me: "If the node/core is down, the
>> entry is taken off the clusterstate and if the core comes up later it
>> is automatically unregistered."
>>
>> That doesn't square with what I'm seeing so either the docs are wrong
>> or I'm misunderstanding the intent.
>>
>> If the node _is_ up, then it's removed from the node and clusterstate
>> and stays gone.
>>
>> Personally, I don't particularly like the idea of queueing up the
>> DELETEREPLICAS for later execution, seems like it's overly complex.
>> Having the clusterstate info removed if the node is down seems very
>> useful though.
>>
>> Thanks,
>> Erick
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.

Reply via email to