Fix indices shown in _cat/indices#43286
Conversation
|
Pinging @elastic/es-core-features |
|
@elasticmachine run elasticsearch-ci/1 |
This is a breaking change but I don't come with a better solution to correctly resolved authorized indices before retrieving other information. |
|
@elasticmachine update branch |
|
Can we use the cluster health request to resolve the authorized indices instead of using the newly added Get Index request? |
| sendIndicesStatsRequest(concreteIndices, indicesOptions, includeUnloadedSegments, client, step3); | ||
| }, listener::onFailure); | ||
|
|
||
| final StepListener<Map<String, IndexMetaData>> step4 = new StepListener<>(); |
There was a problem hiding this comment.
could step 2, 3 and 4 run in parallel?
There was a problem hiding this comment.
Yes, I used a GroupedActionListener for this.
The way the Cluster Health API works prevent us from using it to resolve the authorized indices: when using the Cat Indices API, the user requires the appropriate privilege to get the cluster state ( I'm not a big fan of adding another privilege and call for this _cat/indices but I don't have a better idea for now. I'm waiting for some ideas @albertzaharovits :) |
|
Hi @tlrx , |
|
@elasticmachine run elasticsearch-ci/1 |
|
@albertzaharovits Thanks for your suggestion, it seems to work nicely :). Can you have a look please? |
albertzaharovits
left a comment
There was a problem hiding this comment.
I believe we should keep the original behavior with respect to wildcards that are expanded with the same options by all APIs. This prevents errors when the wildcard expands to indices that are subsequently removed before the other calls. This is my only objection and in case I'm not mistaken can be rectified easily.
I'll LGTM for now.
Thank you Tanguy for tackling fallouts of my changes!
|
|
||
| sendIndicesStatsRequest(concreteIndices, indicesOptions, includeUnloadedSegments, client, groupedListener); | ||
| sendClusterStateRequest(concreteIndices, indicesOptions, local, masterNodeTimeout, client, groupedListener); | ||
| sendClusterHealthRequest(concreteIndices, indicesOptions, local, masterNodeTimeout, client, groupedListener); |
There was a problem hiding this comment.
Why do we use the concreteIndices rather than indices with indicesOptions. There is a comment in the original code:
...
// This behavior can be ensured by letting the cluster health and indices
// stats requests re-resolve the index names with the same indices options
// that we used for the initial cluster state request (strictExpand).
that I believe still applies (if wildcards expand to indices that are subsequently deleted, we should not error).
There was a problem hiding this comment.
Yes, this is not good. I restored the original comment and behavior in 4eb76f5
| public void onFailure(final Exception e) { | ||
| listener.onFailure(e); | ||
| } | ||
| }); |
There was a problem hiding this comment.
this can be simplified.
|
|
||
| @Override | ||
| public void onFailure(final Exception e) { | ||
| listener.onFailure(e); |
There was a problem hiding this comment.
this can be simplified to client.admin().cluster().health(request, listener)
there are 3 occurrences of this.
There was a problem hiding this comment.
There's still a need to downcast - I pushed ff35567
| }; | ||
| } | ||
|
|
||
| private void sendGetSettingsRequest(final String[] indices, |
There was a problem hiding this comment.
can you add a comment why we're using getSettings request here? i.e. that it is used to resolve the indices.
|
@elasticmachine run elasticsearch-ci/1 |
After two recent changes (elastic#38824 and elastic#33888), the _cat/indices API no longer report information for active recovering indices and non-replicated closed indices. It also misreport replicated closed indices that are potentially not authorized for the user. This commit changes how the cat action works by first using the Get Settings API in order to resolve authorized indices. It then uses the Cluster State, Cluster Health and Indices Stats APIs to retrieve information about the indices. Closes elastic#39933
After two recent changes (#38824 and #33888), the _cat/indices API no longer report information for active recovering indices and non-replicated closed indices. It also misreport replicated closed indices that are potentially not authorized for the user. This commit changes how the cat action works by first using the Get Settings API in order to resolve authorized indices. It then uses the Cluster State, Cluster Health and Indices Stats APIs to retrieve information about the indices. Closes #39933
After two recent changes (elastic#38824 and elastic#33888), the _cat/indices API no longer report information for active recovering indices and non-replicated closed indices. It also misreport replicated closed indices that are potentially not authorized for the user. This commit changes how the cat action works by first using the Get Settings API in order to resolve authorized indices. It then uses the Cluster State, Cluster Health and Indices Stats APIs to retrieve information about the indices. Closes elastic#39933
After two recent changes (#38824 and #33888), the _cat/indices API no longer report information for active recovering indices and non-replicated closed indices. It also misreport replicated closed indices that are potentially not authorized for the user. This commit changes how the cat action works by first using the Get Settings API in order to resolve authorized indices. It then uses the Cluster State, Cluster Health and Indices Stats APIs to retrieve information about the indices. Closes #39933
After two recent changes (#38824 and #33888), the
_cat/indicesAPI no longer report information for active recovering indices and non-replicated closed indices. It also misreport replicated closed indices that are potentially not authorized for the user.This commit changes how the cat action works by first using the Get Settings API in order to resolve authorized indices. It then uses the Cluster State, Cluster Health and Indices Stats APIs to retrieve information about the indices.
Since the health and the stats of the indices are not guaranteed to exist (ex: recovering indices have a health status but no index stats; non-replicated closed indices have no health and no stats) they are shown only if they are present.
Closes #39933