rack awareness allocation and allocation filtering lead to unassigned shards

[kamaradclimber]

Using shard awareness and allocation filtering together may lead to unassigned shard.

To reproduce:

• 3 nodes cluster (2 with node.flavor: type1, the other one with node.flavor: type2)
• shard are required to have 2 copies
• use cluster.routing.allocation.awareness.attributes: flavor
• use routing.allocation.require: type1 on index template

On index creation, shard primary will be set on a type1 node, its copy will stay unassigned.

The full description of the scenario leading to this issue is described on #8104 and https://groups.google.com/forum/#!topic/elasticsearch/wbVIsDzYLDM

Investigation in the code show that

• shard allocation on type2 node is ruled out because of allocation filter
• shard allocation on type1 nodes are ruled out because of rack awareness

Those rules should cooperate and I expect the shard replica to go to the second type1 node.

[elasticmachine]

Pinging @elastic/es-distributed

[DaveCTurner]

This is a known issue to do with the interaction of shard allocation settings, but since its opening we have not seen enough feedback that it is something we should work on. We prefer to close this issue as a clear indication that we are not going to work on this at this time. We are always open to reconsidering this in the future based on compelling feedback; despite this issue being closed please feel free to leave feedback (including +1s).