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.
