<p dir="auto">Being able to close indices is a great way to reduce memory usage in an ES cluster with lots of indices.  Unfortunately, it makes cluster expansion less automatic -- closed indices don't want to relocate when new nodes are added to the cluster.</p>
<p dir="auto">It would be great it one could instruct ES to allow relocation of closed indices, too.</p>
<p dir="auto">Similarly, imagine you have an index with 1 replica.  Imagine this index is closed.  Imagine that the node where there the replica was located dies.  Ooops, at this point this index doesn't have a replica.  I don't know if that will turn the index/cluster yellow or ES won't react to that, but it would be great it one could tell ES to create a replica on another node to make up for the lost replica.</p>
<p dir="auto">[2015-02-06 15:09:56,722][INFO ][cluster.service ] [LONTTL-ELS03v] detected_master [LONTTL-ELS01v][He9uLnSxRD2w-w6_4e8d8A][LONTTL-ELS01V][inet[/10.128.3.216:9300]], added {[LONTTL-ELS01v][He9uLnSxRD2w-w6_4e8d8A][LONTTL-ELS01V][inet[/10.128.3.216:9300]],[LONTTL-ELS02v][UPV5NBl2TECGYiExIG_I8A][LONTTL-ELS02v][inet[/10.128.3.218:9300]],}, reason: zen-disco-receive(from master [[LONTTL-ELS01v][He9uLnSxRD2w-w6_4e8d8A][LONTTL-ELS01V][inet[/10.128.3.216:9300]]])</p>
<p dir="auto">LONTTL-ELS03v is on cluster name TTL.LOCAL_MarvelServer</p>
<p dir="auto">LONTTL-ELS02v and LONTTL-ELS01v are on cluster name TTL.LOCAL_ElasticSearch</p>
<p dir="auto">The customer misconfigured the unicast configuration and added the following configuration in all the nodes in both cluster :<br>
discovery.zen.ping.unicast.hosts: ["LONTTL-ELS01v","LONTTL-ELS02v","LONTTL-ELS03v"]</p>
<p dir="auto">The  node LONTTL-ELS01v with one cluster name can discover a master with another cluster name when people misconfigured  unicast discovery,  because we do not check the cluster name in  unicast ping.</p>