ignore_missing removed from _aliases

[rashidkpc]

Continuing discussion from:
#7234 (comment)

It appears that the recent Get Indices API removes ignore_missing:

Elasticsearch 1.3.2

curl -XGET  http://localhost:9200/logstash-2014.09.16,logstash-2014.09.17/_aliases?ignore_missing=true;echo
{"logstash-2014.09.16":{"aliases":{}}}

Elasticsearch 1.4 branch

$ curl -XGET  http://localhost:9200/logstash-2014.09.16,logstash-2014.09.17/_aliases?ignore_missing=true;echo
{"error":"IndexMissingException[[logstash-2014.09.17] missing]","status":404}

Technically ignore_missing was slated for removal in Elasticsearch 1.0 (http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/_parameters.html#_parameters), however it was not removed from this API, meaning this this will introduce a breaking change for 1.4.

It might be better to deprecate ignore_missing and remove it in Elasticsearch 2.0.

[colings86]

The ignore_missing option was removed in 1.0 and in 1.3.2 the flag had not effect (including it or not including it gave the same response). The change in 1.4 was that the API now fully handles IndicesOptions and the default is not to ignore unavailable indices (whereas in 1.3 it would ignore unavailable indices).

The breaking changes documentation was updated in #7786 to more clearly explain the change here

[kevinkluge]

I like Rashid's original proposal to just deprecate ignore_missing and not actually remove it until ES 2.0. We know that this change breaks Kibana 3.x and it's possible it will break other apps people have written.

This is a weird situation, where the docs said it was removed but it really wasn't. I get the argument that this is just a bug fix, but I think our users would be better off if we didn't break this in a minor release like 1.4.

[javanna]

I like Rashid's original proposal to just deprecate ignore_missing and not actually remove it until ES 2.0.

Let me try to clarify what happened, the ignore_missing parameter was actually never supported by this specific api/endpoint. Its behaviour was lenient and not configurable, meaning that the parameter was just being ignored. This api was inconsistent given that its behaviour didn't support our common multi indices options (neither ignore_missing nor ignore_unavailable) and its default was different from the other api (lenient instead of strict).

The only thing we could technically do is keep the inconsistent default and make it lenient if no parameters are specified, but that would mean that the get indices api, the single api that rules them all, would need to have a different behaviour only when returning aliases? That doesn't really make sense to me.

That said, I see this as a bugfix which ended up changing the default behaviour of the aliases endpoint, which is now strict instead of lenient, but configurable. If the fact that the change is breaking we should maybe consider taking the get indices api as a whole out of 1.x?

[clintongormley]

Given that the GET _aliases is a widely used API, and this change does break bwc, I suggest we keep it lenient for 1.x (ie default ignore_unavailable to true), but deprecate this, and change the behaviour in master.