Query processing against aliases with closed indices

[ppf2]

I am separating out the 2 functionalities being discussed as part of #14982 with the creation of this new ticket. For #14982, we will focus on the GET _alias and _cat/aliases reporting of index/alias association.

For this ticket, the focus is on the error message the user will receive if a query is sent to an alias that has a reference to a closed index.

#14982 (comment)

There has been a suggestion to remove any aliases automatically when closing an index, but I think this is not the correct behaviour. If a user wants this, then they can simply DELETE {index}/_alias/* before closing the index.

Per the feedback in the other ticket, it sounds like the current behavior is expected, i.e. if any one of the indices referenced by an alias is closed, all queries to the alias will return a 403 error:

{
   "error": {
      "root_cause": [
         {
            "type": "index_closed_exception",
            "reason": "closed",
            "index": "test"
         }
      ],
      "type": "index_closed_exception",
      "reason": "closed",
      "index": "test"
   },
   "status": 403
}

Feedback we received from the field is that in order to workaround the above, the admins have to always remember to remove the to-be-closed indices from the aliases prior to closing. Otherwise, this can create an outage when end users attempt to query against the alias (instead of getting back results from the indices that are not closed, they get an immediate error message).

Since the current behavior is by design, I am creating this request as an enhancement to discuss if this is something we can automate for the end user (eg. maybe have the close api remove the index from all aliases), or if we can provide a configurable option for users to determine if they want aliases with closed indices to return a 403, or allow queries against the open indices to function and return results, etc..

[allthedrones]

Given the prevalence of advice to use aliases as an abstraction to prevent client applications from being tightly coupled to indexing strategy, I would advocate for at least having the option for a low-drag experience in which closed members of an alias are automatically bypassed. I agree with feedback that it would be incorrect to transparently remove indices from an alias upon close unless they were guaranteed to be transparently restored when re-opened. In every other sense, closing an index seems to represent a state of suspended animation, and the strongly established expectation is that it will be returned to its previous state upon open.

If [optionally] silently bypassing closed indices within an alias is not feasible, it would be nice if the close (and open) API allowed the specification of options to condense the operations: specifying the removal of aliases at close, and re-enrollment into aliases at open. I can see this being useful for a few other settings as well (for instance, I often open an index and immediately change the replica count ... would be really slick to specify that as part of the open call).

Still, as a matter of first preference, if a new user takes the common advice to point their client app(s) at aliases, which are billed as a transcendent/aggregate layer above indices, I think it's potentially confusing & frustrating if changing a single component index results in an outage for the entire alias.

[clintongormley]

@javanna makes me wonder if we should have an expand_aliases option https://www.elastic.co/guide/en/elasticsearch/reference/2.1/multi-index.html

[javanna]

@clintongormley if I read correctly #13278 and the corresponding fix (#15882), we are now checking the state of the indexes after alias resolution and honouring the current indices options, which were not previously applied to aliases. expland_wildcards is now used to expand aliases too. It seems like there is no need for a new option but maybe we need to rename the option as it's getting applied to aliases too. Relates to #9438 at this point.

[javanna]

we are now checking the state of the indexes after alias resolution and honouring the current indices options

I take this back, I had misunderstood, we check the index state if the alias matches a wildcard expression, not when the alias is explicitly specified. I find this confusing, digging a bit more to find out what we can do about it.

[javanna]

GET /alia*/_search will match the alias "alias" and resolve by default to the open indices only. It honours expand_wildcards.

GET /alias/_search will resolve to open and closed indices by default and return an exception, but ignore_unavailable allows to control whether unavailable (closed too) indices should be ignored.

GET /alias/_search?ignore_unavailable=true resolves to the open indices only.

This behaviour doesn't seem that bad to me. Maybe the default for search should be to ignore unavailable? That would be a breaking change though.

[clintongormley]

Thanks @javanna . I'd forgotten about ignore_unavailable. I don't think this should be the default though. If a user searches against an alias with closed indices, they should be made aware of it, rather than the situation being silently ignored.

I think the workaround is already in place, and there is nothing more to do here. Closing