_alias API no longer accepts index wildcards

[spalger]

Elasticsearch version: master
JVM version (java -version): 1.8.0_121
OS version (uname -a if on a Unix-like system): macOS Sierra
Description of the problem including expected versus actual behavior:

It looks like #24723 broke fetching the aliases of a wildcard list of indices:

Steps to reproduce:

master:

with #24723 reverted

[jasontedor]

I concur, although this has nothing to do with wildcards, regular index patterns are impacted too. The reason that this is due to #24723 is because /{index}/_alias use to be specially handled by the get indices API but now it's handed by the get aliases API on the endpoint /{index}/_alias/{name} (so with these requests name would default to empty which acts like _all).

It's not obvious what the right outcome here is. We had the two endpoints before:

• /{index}/_alias
• /{index}/_alias/{name}

It really should have been the case that the former was always handled by the latter. Their behaviors were inconsistent which is why changing the former to be handled by the latter has this outcome. That is, on 5.4.1 today you can see the following:

21:28:56 [jason:~] $ curl -XGET localhost:9200/logstash-0/_alias?pretty=true
{
  "logstash-0" : {
    "aliases" : { }
  }
}
21:33:39 [jason:~] $ curl -XGET localhost:9200/logstash-0/_alias/_all?pretty=true
{ }

I tend to think the latter behavior is the one that we should maintain as that's how all other alias requests were handled except for ones that did not specify any alias name. What is the need for the empty list of aliases if none exist for an index when this can also be inferred from no key matching the index being in the response? So maybe it's enough to document the impact of #24723?

[jasontedor]

What do you think @dakrone?

[dakrone]

I tend to think the latter behavior is the one that we should maintain as that's how all other alias requests were handled except for ones that did not specify any alias name.
What do you think @dakrone

I believe I agree with this statement, as @jasontedor said, this isn't about wildcards, as the following still works:

PUT /real

PUT /real2

POST /_aliases?pretty
{
  "actions": [
    {"add": {"index": "real", "alias": "fake"}},
    {"add": {"index": "real", "alias": "fake2"}},
    {"add": {"index": "real2", "alias": "realfake"}}
  ]
}

GET /real*/_alias

Which returns

{
  "real" : {
    "aliases" : {
      "fake" : { },
      "fake2" : { }
    }
  },
  "real2" : {
    "aliases" : {
      "realfake" : { }
    }
  }
}

Therefore, I'm in favor of documenting the breaking change also I think. What do you think @spalger?

[clintongormley]

I tend to think the latter behavior is the one that we should maintain as that's how all other alias requests were handled except for ones that did not specify any alias name. What is the need for the empty list of aliases if none exist for an index when this can also be inferred from no key matching the index being in the response? So maybe it's enough to document the impact of #24723?

I disagree. The GET {index}/_alias form is widely used to retrieve a list of concrete indices, and it would silently break lots of applications.

Also, it would be inconsistent:

PUT t 
GET t
GET t/_alias
GET t/_mapping

which returns:

# PUT t
{
  "acknowledged": true,
  "shards_acknowledged": true
}

# GET t
{
  "t": {
    "aliases": {},
    "mappings": {},
    "settings": {
      "index": {
        "creation_date": "1496818805172",
        "number_of_shards": "5",
        "number_of_replicas": "1",
        "uuid": "tx4bhuh6Sheu2dSN_kSo4A",
        "version": {
          "created": "6000003"
        },
        "provided_name": "t"
      }
    }
  }
}

# GET t/_alias
{}

# GET t/_mapping
{}

For clients that want to check eg aliases, they now need to first check if there is an _aliases key before inspecting the contents.

I'd much prefer a consistent rule:

• return zero or more concrete indices at the top level
• under each index, there is an _aliases key
• under which there is a list of zero or more aliases

same applies to mappings and settings (there are always settings)

In other words, a final missing parameter behaves like *

[dakrone]

@clintongormley it sounds like you want to see:

GET /test-*/_alias
{
  "test-1": {
    "_aliases": {}          // no aliases
  },
  "test-2": {
    "_aliases": {
      "myalias": {}
    }
  }
}

under each index, there is an _aliases key

Are you sure you want it to be _aliases instead of aliases like the get indices API? That doesn't seem consistent with the older API to me

[clintongormley]

Are you sure you want it to be _aliases instead of aliases like the get indices API? That doesn't seem consistent with the older API to me

Sorry, meant aliases

[dakrone]

Sounds good, I will work on fixing this.