anchor.diff:  Make write calls return the number of total/successful/missing shards in the same way that we do in search, which ensures transparency in the consistency of write operations. {GIT}7994[#7994]. (STATUS: DONE, v2.0.0)
   
   [float]
  -=== Simplify and harden shard recovery and allocation (STATUS: ONGOING)
  +=== Jepsen Test Failures (STATUS: ONGOING)
  +
  +We have increased our test coverage to include scenarios tested by Jepsen. We make heavy use of randomization to expand on the scenarios that can be tested and to introduce new error conditions. You can follow the work on the master branch of the https://github.com/elasticsearch/elasticsearch/blob/master/src/test/java/org/elasticsearch/discovery/DiscoveryWithServiceDisruptions.java[`DiscoveryWithServiceDisruptions` class], where we will add more tests as time progresses.
  +
  +[float]
  +=== Document guarantees and handling of failure (STATUS: ONGOING)
  +
  +This status page is a start, but we can do a better job of explicitly documenting the processes at work in Elasticsearch, and what happens in the case of each type of failure. The plan is to have a test case that validates each behavior under simulated conditions. Every test will document the expected results, the associated test code and an explicit PASS or FAIL status for each simulated case.
  +
  +
  +[float]
  +=== Take filter cache key size into account (STATUS: ONGOING)
  +
  +Commonly used filters are cached in Elasticsearch. That cache is limited in size (10% of node's memory by default) and is being evicted based on a least recently used policy. The amount of memory used by the cache depends on two primary components - the values it stores and the keys associated with them. Calculating the memory footprint of the values is easy enough but the keys accounting is trickier to achieve as they are, by default, raw Lucene objects. This is largely not a problem as the keys are dominated by the values. However, recent optimizations in Lucene have changed the balance causing the filter cache to grow beyond it's size.
  +
  +While we are working on a longer term solution ({GIT}9176[#9176]), we introduced a minimum weight of 1k for each cache entry. This puts an effective limit on the number of entries in the cache. See {GIT}8304[#8304] (STATUS: DONE, fixed in v1.4.0)
  +
  +== Completed
  +
  +[float]
  +=== Ensure shard state ID is incremental (STATUS: DONE, v1.5.1)
  +
  +It is possible in very extreme cases during a complicated full cluster restart,
  +that the current shard state ID can be reset or even go backwards.
  +Elasticsearch now ensures that the state ID always moves
  +forwards, and throws an exception when a legacy ID is higher than the
  +current ID.  See {GIT}10316[#10316] (STATUS: DONE, v1.5.1)
  +
  +[float]
  +=== Verification of index UUIDs (STATUS: DONE, v1.5.0)
  +
  +When deleting and recreating indices rapidly, it is possible that cluster state
  +updates can arrive out of sync and old states can be merged incorrectly.  Instead,
  +Elasticsearch now checks the index UUID to ensure that cluster state updates
  +refer to the same index version that is present on the local node.
  +See {GIT}9541[#9541] and {GIT}10200[#10200] (STATUS: DONE, Fixed in v1.5.0)
  +
  +[float]
  +=== Disable recovery from known buggy versions (STATUS: DONE, v1.5.0)
  +
  +Corruptions have been known to occur when doing a rolling restart from older, buggy versions.
  +Now, shards from versions before v1.4.0 are copied over in full and recovery from versions
  +before v1.3.2 are disabled entirely. See {GIT}9925[#9925] (STATUS: DONE, Fixed in v1.5.0)
  +
  +
  +[float]
  +=== Upgrade 3.x segments metadata on engine startup (STATUS: DONE, v1.5.0)
  +
  +Upgrading the metadata of old 3.x segments on node upgrade can be error prone
  +and can result in corruption when merges are being run concurrently. Instead,
  +Elasticsearch will now upgrade the metadata of 3.x segments before the engine
  +starts.  See {GIT}9899[#9899] (STATUS; DONE, fixed in v1.5.0)
  +
  +[float]
  +=== Prevent setting minimum_master_nodes to more than the current node count (STATUS: DONE, v1.5.0)
  +
  +Setting `zen.discovery.minimum_master_nodes` to a value higher than the current node count
  +effectively leaves the cluster without a master and unable to process requests.  The only
  +way to fix this is to add more master-eligibile nodes.  {GIT}8321[#8321] adds a mechanism
  +to validate settings before applying them, and {GIT}9051[#9051] extends this validation
  +support to settings applied during a cluster restore. (STATUS: DONE, Fixed in v1.5.0)
  +
  +[float]
  +=== Simplify and harden shard recovery and allocation (STATUS: DONE, v1.5.0)
   
   Randomized testing combined with chaotic failures has revealed corner cases
   where the recovery and allocation of shards in a concurrent manner can result
  
positive.code: A test to replicate this condition was added in {GIT}7493[#7493].
  
  [float]
  === Prevent use of known-bad Java versions (STATUS: ONGOING)
  
  Certain versions of the JVM are known to have bugs which can cause index corruption.  {GIT}7580[#7580] prevents Elasticsearch startup if known bad versions are in use.
  
  [float]
  === Lucene checksums phase 3 (STATUS:ONGOING)
  
  Almost all files in Elasticsearch now have checksums which are validated before use.  A few changes remain:
  
  * {GIT}7586[#7586] adds checksums for cluster and index state files. (STATUS: DONE, Fixed in v1.5.0)
  * {GIT}9183[#9183] supports validating the checksums on all files when starting a node. (STATUS: DONE, Fixed in v2.0.0)
  * {JIRA}5894[LUCENE-5894] lays the groundwork for extending more efficient checksum validation to all files during optimized bulk merges. (STATUS: ONGOING, Fixed in Lucene 5.0)
  * {GIT}8403[#8403] to add validation of checksums on Lucene `segments_N` files. (STATUS: NOT STARTED)
  
  [float]
  
negative.code: We are committed to tracking down and fixing all the issues that are posted.
  
  [float]
  === Make index creation more user friendly (STATUS: ONGOING)
  
  Today, Elasticsearch returns as soon as a create-index request has been processed,
  but before the shards are allocated.  Users should wait for a `green` cluster health
  before continuing, but we can make this easier for users by waiting for a quorum
  of shards to be allocated before returning.  See {GIT}9126[#9126]
  
  [float]
  === Better request retry mechanism when nodes are disconnected (STATUS: ONGOING)
  
  If the node holding a primary shard is disconnected for whatever reason, the
  