It is totally possible. The point is , it was not a security feature and it is extremely easy to spoof it. The question is , was it a normal scenario or was it an effort to prove that the system was not foolproof
--Noble On Thu, Mar 12, 2015 at 6:23 PM, Varun Thacker <[email protected]> wrote: > Two scenarios I observed where we can bring up a replica even when I think > it shouldn't. legacyCloud is set to false. > > - I have two nodes A and B. > - CREATE collection 'test' with 1 shard, 1 replica. It gets created on > node A. > - manually copy test_shard1_replica1 folder to node B's solr home. > - Bring down node A. > - Restart node B. The shard comes up registering itself on node B and > becomes 'active' > > > - I have two nodes A and B ( this is down currently ). > - CREATE collection 'test' with 1 shard, 1 replica. It gets created on > node A. > - manually copy test_shard1_replica1 folder to node B's solr home. > - Start node B. The shard comes up registering itself on node B and > stays 'down'. The reason being the leader is still node A but clusterstate > has base_url of Node B. This is the error in the logs - "Error getting > leader from zk for shard shard1 > > In legacyCloud=false you get a 'no_such_replica in clusterstate' error if > the 'coreNodeName' is not present in clusterstate. > > But in my two observations the 'coreNodeName' were the same, hence I ran > into that scenario. > > Should we make the check more stringent to not allow this to happen? Check > against base_url also? > > Also should we be making legacyCloud=false as default in 5.x? > -- > > > Regards, > Varun Thacker > http://www.vthacker.in/ > -- ----------------------------------------------------- Noble Paul
